New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

donet publish always updating web.config #115

Closed
mlorbetske opened this Issue Feb 3, 2017 · 39 comments

Comments

Projects
None yet
@mlorbetske
Copy link
Member

mlorbetske commented Feb 3, 2017

From @chrisdrobison at dotnet/cli#5544 (comment)

I'm trying a build a web deploy package that will be deployed to a virtual application in IIS. According to your docs, the aspNetCore handler needs to be defined at the site root and the applications themselves only define the aspNetCore element. But, the even though I comment that handler line out, the dotnet publish-iis command always reinserts the following line:

<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>

Steps to reproduce

  1. Comment out handler line in web.config
  2. Run publish

Expected behavior

Don't insert something I have commented out

Actual behavior

Inserts something I want commented out.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
Version: 1.0.0-preview2-1-003177
Commit SHA-1 hash: a2df9c2576

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Mar 10, 2017

Issues to address:

  1. If a specific section is commented out, then that section should not be transformed.
  2. If a value is already provided for an attribute, then it should not be overwritten.
@johnkors

This comment has been minimized.

Copy link

johnkors commented Mar 28, 2017

Any update?

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Mar 28, 2017

As a work-around, WebConfig transform can be disabled by setting the msbuild property IsTransformWebConfigDisabled to true.

We are working on improving the web.config transform experience.

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 3, 2017

What version of the SDK do I need to use for Visual Studio 2017 to honor the IsTransformWebConfigDisabled property? When I debug, it still changes the <aspNetCore /> element.

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 3, 2017

Not sure, but this seems like a Visual Studio 2017 bug, because it's not honoring this prop even with the 2.0.0-preview2-006497 SDK.

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Aug 3, 2017

is the transform happening during publish ?

setting this should disable the transform during publish.

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>

Condition="'$(_IsAspNetCoreProject)' == 'true' And '$(IsTransformWebConfigDisabled)' != 'true'"

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 4, 2017

Ok, so just to clarify. This is happening

I've altered the element in my source web.config to be explicit about the arguments.

So from:

    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

To:

    <aspNetCore processPath="C:\Program Files\dotnet\dotnet" arguments=".\Commission.Web.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"  />

OK behaviour:

If I use the CLI and do a dotnet run on the same project, the main web.config is not modified.
If I use the CLI and do a dotnet publishon the same project, only the web.config in the published folder is modified - not the source web.config

Weird behaviour:

Whenever I try to hit F5, or run the app from VS2017 - it immedieatly tries to alter the aspNetCore element back to the parameterized %LAUNCHER_PATH% arguments in my main source web.config.

So git sees it's a modification every time I do debug/run using VS.

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Aug 4, 2017

If I use the CLI and do a dotnet publishon the same project, only the web.config in the published folder is modified - not the source web.config

You can pass this property to dotnet publish & it wont modify the web.config in published output
dotnet publish /p:IsTransformWebConfigDisabled=true

If you don't want the web.config to be modified during VS F5, then this property wont help since this is for publish only.

@BillHiebert Is there a way to disable web.config transform on F5?

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 7, 2017

Yep, I'm aware of the IsTransformWebConfigDisabled prop, but it has no effect on the main web.config transformation when hitting F5 unfortunately. I would have thought VS should pick up this if I set

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>

but it's not honoring it like the CLI does. For now I've had to resort to old school web.config transforms to work around the issue.

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented Aug 11, 2017

We changed the behavior to write the ANCM module information in the applicationhost.config instead of the web.config by default. However, if the ANCM module information is already in the web.config we will update that file instead. Can you try removing the information from web.config to see if it fixes things?

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 13, 2017

No, I need to set the path to dotnet.

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented Aug 15, 2017

When hosted in IIS Express (or local IIS), VS will control the values passed to ANCM as it actually launches an intermediate process so that it can control attaching the debugger. There is currently no way to change this. VS will use the dotnet.exe that is first on the path (from a command prompt type "where dotnet.exe" and this will tell which one it is running).

Are you trying to F5 a different dotnet.exe than what is on the path? If so you could create a another launch profile (Properties\Debug tab) and set the commandName to "Executable". You can then configure it to point to the dotnet.exe you want to run. Of course you will need to pass your own command line arguments and you can use any static msbuild property using $(propertyname) syntax to make this a bit easier.

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 15, 2017

No, I'm not debugging another dotnet on my local machine - I just don't want VS to make changes to my web.config.

  1. it'll be a checkout file in Git for everytime a developer on the team debugs something
  2. I need the ANCM config to have a explicitly defined path for the web server I'm deploying to.

I know I can always go around it, for instance revert to web.config transforms deploy time. I just found it very annoying that VS modifies my source code when debugging. Unexpected behaviour that causes every dev on the team to be aware of that this will happen and do a git checkout on the web.config before committing actual changes.

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented Aug 16, 2017

The way to fix this is to remove the ANCM information from web.config (or maybe remove web.config entirely), and add in your custom one as part of deploying the application.

@johnkors

This comment has been minimized.

Copy link

johnkors commented Aug 16, 2017

Yeah, or alternatively just jump ship and use JetBrains Rider. Thanks anyhow.

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented Aug 17, 2017

The other option is to run the project directly from VS ie. don't host it in IIS Express which is basically just a pass through anyway.

@loftum

This comment has been minimized.

Copy link

loftum commented Sep 28, 2017

@johnkors Until fixed, you may also try to do it the old fashioned way by git-ignoring web.config and transform it yourself.
I used my own tool https://github.com/loftum/configmerge and

  • moved web.config to config/web.root.config
  • added config/web.local.config with my local needs
  • added web.config and web.local.config to .gitignore (leaving web.root.config the "prod" web.config)
  • added prebuild event: ConfigMerge.exe -recipe:web.config = config/ + [web.root.config, web.local.config];

Saved me today.

@johnkors

This comment has been minimized.

Copy link

johnkors commented Sep 29, 2017

hah, awesome @loftum ! The DIY-tooling still prevails! 💃

I did have some small hopes that we would not need to revert to our own workarounds for these tings in the "new world", but apparently we still do. 😐

@zkost

This comment has been minimized.

Copy link

zkost commented Jan 5, 2018

This remains an issue. Publishing via vs2017 to IIS 8.5 overwrites web.config file on the IIS server. If you, like me, are using the url re-write module to have rewrite rules setup (in my case, a redirect to https rule). it gets overwritten every time I publish to my IIS server. This is a bug or an oversight at best.

@majorb84

This comment has been minimized.

Copy link

majorb84 commented Feb 27, 2018

Any update on this? Plans to fix?

@WayneHiller

This comment has been minimized.

Copy link

WayneHiller commented Feb 28, 2018

I ran into another issue with the web.config dotnet publish is generating. If your dll has spaces in the name she won't work in IIS.

<aspNetCore processPath="dotnet" arguments='".\AIS Log Viewer.dll"' stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

Note I had to add single quotes around the arguments to make it work.

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Feb 28, 2018

I will bump up the priority of this issue.

@ot-alex-vance

This comment has been minimized.

Copy link

ot-alex-vance commented Feb 28, 2018

Can confirm this worked for me as well.

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>

@vijayrkn

This comment has been minimized.

@DerekZiemba

This comment has been minimized.

Copy link

DerekZiemba commented Mar 13, 2018

I can't start the debugger or publish because of this issue. Furthermore the <IsWebConfigTransformDisabled> and <IsTransformWebConfigDisabled> have no effect what so ever. I'm not sure where to go from here.

Watch the issue in real time:
GIF of it happening in real time

@aarrttzz

This comment has been minimized.

Copy link

aarrttzz commented Apr 12, 2018

I lost 3 days to found out it. IsTransformWebConfigDisabled dont work!

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Apr 12, 2018

@DerekZiemba @aarrttzz
<IsWebConfigTransformDisabled> and <IsTransformWebConfigDisabled> are only used at Publish time.

After setting this property, when you run 'dotnet publish' (or equivalent), then the web.config will not be transofmed by the publish process. But from the above screencast, it is not clear whether a publish is even happening here.

@emes001

This comment has been minimized.

Copy link

emes001 commented May 2, 2018

Since this occurs with a F5 (Debug) in Visual Studio, is this a VS bug? I unfortunately lost 6 hours of productivity yesterday troubleshooting this.

My scenario is two ASP.Net Core apps running as a parent/child within a root website hosted in IIS. If I keep the parent's web.config unmodified (as generated by a F5 in VS), I'm unable to run the child app (it gives a 500, because it inherited the parent's web.config which already has aspNetCore specified). My immediate workaround was to add a tag and prevent inheritance from the parent into the child. This worked (and both projects "run", woo!). That is, until I need to debug the parent. It then modifies the web.config (where the only modification was to add a wrapping location tag), which then again breaks my child application.

@johnkors

This comment has been minimized.

Copy link

johnkors commented May 2, 2018

@emes001 , yes that was my experience as well. This is VS. The CLI honors the do-not-touch-web-config-setting, whilst VS is just flipping you off regardless.

#115 (comment)

I ended up using old school web.config transforms to bypass the issue with VS. 🐼

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented May 2, 2018

@emes001 We have an issue open to address the inheritance problem. The addition of the location tag is unexpected. Can you provide a before an after web.config file? Thanks

@emes001

This comment has been minimized.

Copy link

emes001 commented May 2, 2018

Parent app:
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" /> </system.webServer> </location> </configuration>

Child app:
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" startupTimeLimit="3600" requestTimeout="23:00:00" stdoutLogEnabled="false" /> </system.webServer> </configuration>

This configuration allows both to run in IIS (website host > parent app (/application) > child app (/application/api), when mapped to the project's directory (unpublished version).

From the parent app, if I hit F5, I get an error in VS: "Unable to start process C:\Program Files\dotnet\dotnet.exe. The web server request failed with status code 500, Internal Server Error. The full response has been written to (path to file)."

If I then reload the web.config file, it was transformed into the following:

<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" /> </system.webServer> </location> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" startupTimeLimit="3600" requestTimeout="23:00:00" stdoutLogEnabled="false" /> </system.webServer> </configuration>

If I comment out the location tag, I can hit F5 and debug my parent app as necessary. However this now breaks my child app (API), because the aspNetCore tag is present in both the parent and child's web.configs. If I comment out the (newly added) system.webServer tag, both my parent and child application are happy, but I'm unable to debug the parent.

No update is necessary to my child application, in order to run or debug.

@BillHiebert

This comment has been minimized.

Copy link
Contributor

BillHiebert commented May 2, 2018

@emes001 thanks for additional information. Yes, VS is not recognizing the handler is already present in the location section. We'll fix this as part of addressing the inheritInChildApplications="false" issue.

@sepehr1014

This comment has been minimized.

Copy link

sepehr1014 commented May 22, 2018

Any updates on this issue?

@zhaparoff

This comment has been minimized.

Copy link

zhaparoff commented Jun 7, 2018

The same question: any updates? This becomes a bit frustrating over weeks...

@MattWorkWeb

This comment has been minimized.

Copy link

MattWorkWeb commented Jun 13, 2018

I've run into this as well. As I publish to Azure, web.config gets modified and published with invalid values for processpath and arguments.

Can I disable the publish of web.config (i.e., so I can get it right in Azure App Service) and then it won't be updated the next time I publish?

@peterdol

This comment has been minimized.

Copy link

peterdol commented Jun 14, 2018

On my setup (.net core 2.0, Visual Studio Code, OSX) adding the following property to the csproj works (I also cleaned up the publish output directory):

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>

(IsWebConfigTransformDisabled does not work by the way ;-))

@RehanSaeed

This comment has been minimized.

Copy link

RehanSaeed commented Jun 25, 2018

Is it possible to disable the generation of a web.config file completely? The use case being, that you are not using IIS and want to create a small and compact Dockerfile.

@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Jun 25, 2018

You can set any of these properties to disable web.config transform during publish

Condition="'$(_IsAspNetCoreProject)' == 'true' And '$(IsTransformWebConfigDisabled)' != 'true' And '$(IsWebConfigTransformDisabled)' != 'true'"

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
or
<IsWebConfigTransformDisabled>true</IsWebConfigTransformDisabled>
@vijayrkn

This comment has been minimized.

Copy link
Contributor

vijayrkn commented Aug 28, 2018

All these issues should be fixed in the latest update.

Also, XDT support is available during publish - #392

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment