Publish-IIS needs an option to exclude the handlers add section for child sites

[Tratcher]

[Summarized from a customer]

I want to expose the sites
http://www.localdev.com/
http://www.localdev.com/app1
http://www.localdev.com/app2

the root web site, site1 and site2 are all separate asp.net core projects with their own solution (.sln) files and publish settings.

Navigate to http://www.localdev.com works and the root site renders the page

Navigate to http://www.localdev.com/site1 fails with a invalid configuration error. To fix, I go into the published web.config of the site1 project and delete the <handlers>…</handlers> section. However now I’m changing the web.config that the publish tool created so the next time I publish my change to the published web.config gets over-written

Removing the handlers section in child sites is required because it is inherited from the parent site.

publish-iis should have an option to exclude the handlers section for child sites on publish.

[moozzyk]

Publish-iis was for simple scenarios. For more complicated scenarios - isn't it just better to have a custom web.config in the repo and use this?

[mikedice]

I wouldn't exactly consider that URL configuration I mentioned above to be complicated (not simple) :)
Either way though yea being able to check in a web.config that didn't change would be an OK solution as long as it worked. But, it doesn't. If I comment out the handlers section from the checked in web.config the publish just puts it back in. So, publish would have to not over-write my checked in file. And, it would be nice if I could exclude the handlers section in the Development environment and leave it in for Production.

[Tratcher]

Child sites are pretty common, this issue comes up in forums about ever two weeks.

[moozzyk]

The idea is that if you have your own web.config in the repo then you just remove the publish-iis from your project.json entirely (i.e. remove the command from postpublish script and also the package from the tools section).
The reason I am not very fond of the additional parameter is that there is not a good way to pass it to publish-iis. dotnet publish does not pass any arguments it did not consume so the only way to do this would be to edit the command in postpublish which, I think is, fragile. This might change however with MSBuild - when publish-iis is an MSBuild tasks passing additional parameters will be probably much easier.

[Tratcher]

But then you need two web.config's, one for IIS Express / dev and one for publish.

[mikedice]

Spent some time trying to figure out how to do an environment specific override such that for debug on the dev machine we just publish the checked in web.config but I don't see a way to do that. Let me know if anyone has any ideas. I think the web.config transform process is no longer supported in asp.net core or I would have just used that.

[nil4]

@mikedice you can have transforms with asp.net core if you don't mind an unofficial solution. It looks like there are plans for an eventual official port as well.

[moozzyk]

@Tratcher - don't you need two configs as soon as you start using features not supported by IISExpress?

@mikedice - one way to do this is to have the web.config used for production copied in the postpublish step (i.e. instead of using the publish-iis tool just copy the web.config you want to use in production to the target publish folder).

[Tratcher]

VS doesn't publish for IIS Express, it uses the web.config in place with environment variables. You'd need the handlers section for express and then an option to exclude it during publish.

[muratg]

Backlogging this for now. Tools are under churn due to msbuild work. This tool in particular will likely be an msbuild target.

[nil4]

For anyone still waiting for the official solution, dotnet-transform-xdt is updated with MSBuild/csproj support and samples are available, including this use case: https://github.com/nil4/xdt-samples#remove-handlers