Closed Tratcher closed 7 years ago
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?
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.
Child sites are pretty common, this issue comes up in forums about ever two weeks.
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.
But then you need two web.config's, one for IIS Express / dev and one for publish.
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.
@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.
@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).
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.
Backlogging this for now. Tools are under churn due to msbuild work. This tool in particular will likely be an msbuild target.
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
Closing this as MSBuild tooling has been released an the publish-IIS tooling has been completely rewritten. If you are still experiencing issues with publishing for IIS with the .NET Core 1.0.0 tooling, you can open issues on https://github.com/aspnet/websdk.
@natemcmaster Might be worth adding some information here on how to stop the problem with the current tooling (because this issue ranks high in search engines for the issue). I am currently facing this issue and I don't know if I should be going down the dotnet-transform-xdt route or if I have better options.
edit: Good info here https://github.com/aspnet/websdk/issues/115#issuecomment-289816754
tldr:
$ dotnet publish /p:IsTransformWebConfigDisabled=true
[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-writtenRemoving 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.