Support XDT Web.config transforms when publishing

[nil4]

Application-specific configuration values that differ per-environment are supported well through the ASP.NET Core configuration system. For many applications, the IIS hosting configuration defined in Web.config also needs to be adapted to the target deployment environment (at a minimum, to distinguishing between development and production scenarios).

ASP.NET tooling in Visual Studio historically supported XDT transforms that are applied at publish time, and the project templates include these by default. Furthermore, since ASP.NET Core moved the Web.config file to the project root folder, the VS 15 preview tooling automatically adds Web.Debug.config and Web.Release.config transforms. A request to support this feature is tracked at aspnet/Tooling#252.

With the IIS publishing moving to this repo, I think XDT Web.config transforms at publish time should be considered here rather than in the VS tooling. Opening this issue for discussion and feedback.

[muratg]

publish-iis tool and web.config are mainly IIS concepts. ASP.NET Core apps can run directly on Kestrel, or behind nginx too.

You could write a tool (similar to publish-iis) to make web.config transformations that can run as part of your post-publish scripts.

[nil4]

I will give it a try, using the code from https://git01.codeplex.com/xdt as a starting point.

[guardrex]

@nil4 It was a breeze using publish-iis as a template by cloning Microsoft.AspNetCore.Server.IISIntegration.Tools from https://github.com/aspnet/IISIntegration/tree/dev/src/Microsoft.AspNetCore.Server.IISIntegration.Tools. It took me 15 minutes to hack up my changes ... #144 (comment)

[nil4]

@guardrex thanks, that's pretty cool! My use case is a bit different though: we have multiple apps that each use slightly different IIS settings per-environment (e.g. URL rewrite rules, authentication configuration, request limits, etc.) We are comfortable using XDT transforms so I would prefer to have a general-purpose tool that can customize each app's Web.config at publish time. As a bonus, I hope to learn how to write (and test) a dotnet tool.

[guardrex]

It's a command line application, so you have a Program:Main and the ability to read command line arguments passed in when you call it with postpublish in the parent project ... and really anything else anywhere in the parent project files (via parsing them) or in the published output ... and info on the environment (e.g., machine name, env vars, etc.).

Therefore, all you need to do is pickup the environment however it makes sense for your process inside the Program:Main, then use that knowledge in WebConfigTransform.cs to style your web.config however you like.

This is a wonderful tooling system, and @moozzyk gets a BIG 👍 based on the quality work he put into that particular tool. In addition to being a great tool to help with web.config, it also makes for a great template for other similar types of file modification tools that folks will want to create.

I think you'll have a great time and have a low barrier for what you'd like to do.

[nil4]

Well, it took a bit longer than expected, but I got the initial port working: GitHub repo and NuGet package.

There are a few rough spots noted down as known issues (mainly diagnostics), but it's working well enough for my main use cases. Hopefully it will be useful for someone else too. Feedback is welcome!

I did not manage to port the unit tests in the time I set aside for this, so that's still on the to-do list.

[davidfowl]

@nil4 Why do you have the tool in both the tools section and dependencies section? Is it also used at runtime?

[nil4]

@davidfowl good question! While I was developing locally, I used dotnet pack to create the tool NuGet package and had a test project where I was installing it to test (using a local folder as NuGet source, before the package was published to NuGet). Not because I particularly enjoyed this setup, but https://github.com/dotnet/cli/issues/3239.

If I didn't add the package to the dependencies section, I got this:

> dotnet build
Project XdtTest (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing
Compiling XdtTest for .NETCoreApp,Version=v1.0

Compilation succeeded.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:02.1660628
Failed to make the following project runnable: XdtTest (.NETCoreApp,Version=v1.0) reason: Expected coreclr library not found in package graph. Please try running dotnet restore again.

Today I tested from another machine, one that does not have a local version of the package. It picked it up from NuGet and it worked as expected when installed just under the tools section. 👍

Back at home, I tried again. As soon as I add the local NuGet source I get the error above; when I use just nuget.org, everything works as expected. 😕

So I updated the readme file to reflect that only the tools section needs to be populated (thank you for pointing that out!). I hope that helps anyone looking to use the tool.

[nil4]

A generic dotnet CLI tool for XDT transforms is available for both project.json-based and MSBuild/csproj-based projects that enables config transformations. A couple of sample projects demonstrating Web.config transformations at publish time are also available.

[mayconpires]

I have a problem like that:

The Visual Studio add automatically the nodes inside :

<environmentVariable name="DOTNET_ADDITIONAL_DEPS" value="C:\Program Files\dotnet\additionalDeps\Microsoft.AspNetCore.ApplicationInsights.HostingStartup" /> <environmentVariable name="ASPNETCORE_HOSTINGSTARTUPASSEMBLIES" value="Microsoft.AspNetCore.ApplicationInsights.HostingStartup" />

But my web.[debug or release].conf don't have this node.

I remove the nodes of ApplicationInsights of web.config and resolve my problem.
Because, i don't use ApplicationInsights in my system, remove the nodes.

Thanks.

[muratg]

Hi, it looks like you are posting on a closed issue/PR/commit!

We're very likely to lose track of your bug/feedback/question unless you:

1. Open a new issue
2. Explain very clearly what you need help with
3. If you think you have found a bug, include detailed repro steps so that we can investigate the problem