Skip to content
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

Enable web.config transforms for AspNetCore projects in VS #2019

Closed
oliverjanik opened this issue May 1, 2017 · 91 comments
Closed

Enable web.config transforms for AspNetCore projects in VS #2019

oliverjanik opened this issue May 1, 2017 · 91 comments
Labels
Milestone

Comments

@oliverjanik
Copy link

@oliverjanik oliverjanik commented May 1, 2017

Let me prefix this by saying that I'm no fan of web.config but experience of publishing AspNetCore apps to IIS is really poor.

The configuration system of AspNetCore revolves around ASPNETCORE_ENVIRONMENT variable based on which different configs can be loaded and applied.

Setting this variable for specific deployments is a nightmare and there seems to be a lot of confusion how to go about this:

The crux of the problem seems to boil down to 2 problems:

  1. web.config transforms as we know them are not supported in ASP.NET Core projects in VS
  2. the only reasonable way to change ASPNETCORE_ENVIRONMENT is using web.config

Setting a global ASPNETCORE_ENVIRONMENT is not an option as that sets it for every site on a single server. web.config used to be self contained configuration. This dependency on a global env variable is no good in IIS use case.

All in all, I believe the IIS publish story should be of concern as many dev such as myself who are transitioning to AspNetCore want to use their existing infrastructure for deployments and take it step by step. Currently this story is overly complicated and not complete.

Another example where I need web.config transforms: #1701 (comment)

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented May 1, 2017

FWIW, I agree. We just need to be clear that it's for IIS settings. The other thing is the fact that we've moved away from having a default web.config in the template so that would need to be figured out.

/cc @sayedihashimi

@mindingdata

This comment has been minimized.

Copy link

@mindingdata mindingdata commented May 1, 2017

Is this just for IIS though? I think the crux of the issue is the use of ASPNETCORE_ENVIRONMENT variable fullstop to let a website know which environment it is in.

I think a pretty common scenario is for various staging/QA environments to be hosted on the same box in the same IIS instance. There might be 3 teams all with their own "environments" that they can deploy to to test their code (Say deploy a particular branch), but they are all using the same box.

If we take some example code for how appsettings.json is switched per environment :

public Startup(IHostingEnvironment env)
{
	var builder = new ConfigurationBuilder()
		.SetBasePath(env.ContentRootPath)
		.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
		.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
		.AddEnvironmentVariables();
	Configuration = builder.Build();
}

The scenario above is not going to work because the environment variable is system wide. It could be IIS, nginix etc sitting infront of it and the swapping of configuration is not going to work.

Most times I have seen the above come up, suggestions have come up to use Docker, or use something like Puppet/Chef to manage app configuration so there is no appsettings.{env}.json, but I think that makes the path from full framework MVC that much harder.

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented May 1, 2017

@mindingdata You can actually control the logic that determines where the environment comes from in your Program.cs. The environment variable is just one way to declare that (the main way). If you want to do something else based on some magic file or time of day then call UseEnvironment(environmentName) on the WebHostBuidler

@oliverjanik

This comment has been minimized.

Copy link
Author

@oliverjanik oliverjanik commented May 2, 2017

Just to clarify, this is absolutely just for IIS config. Current JSON config system for app settings is quite good and I fully recommend it.

@dkent600

This comment has been minimized.

Copy link

@dkent600 dkent600 commented Jun 26, 2017

To muddy things further: I find that when I use web.config to try to override the system environment setting, it simply doesn't work. When my system environment setting is set to "Development" and I try to set it to "Production" using the web.config (as below), the application still thinks it is running in Development. (ASP.NET Core app running in IIS).

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>
@martinRocks

This comment has been minimized.

Copy link

@martinRocks martinRocks commented Aug 29, 2017

I think this is the right place. I build a N-tier demo and I can't seem to figure out how to inject IHostingEnvironment in to my data access layer project. That project is where I access my database and the only way I got the connection string to that layer was to override the OnConfiguring method with a magic string of the config file.

I also looked at slow-cheetah, but that seems like going around the current method of either "Debug, Release" or "Development, Production" depending on if you are using the VS method or the environment variables.

There must be information that I'm missing. MS can't want everyone to build single tier apps.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
           var builder = new ConfigurationBuilder().SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json");
            
            var config = builder.Build();
            var connstr = config.GetConnectionString("connStr");            
            optionsBuilder.UseSqlServer(connstr);
        }
@TheBeardedLlama

This comment has been minimized.

Copy link

@TheBeardedLlama TheBeardedLlama commented Oct 24, 2017

so has there been any progress on this?

we should be able to set the env in the config for an app without resorting to magic

@DaleMckeown

This comment has been minimized.

Copy link

@DaleMckeown DaleMckeown commented Oct 25, 2017

Yeah I'd like some progress on this too. Currently have no idea how I'm supposed to publish seperate projects to the same box using different environment variables.

@DaleMckeown

This comment has been minimized.

Copy link

@DaleMckeown DaleMckeown commented Oct 26, 2017

I ended coming up with a fairly simple solution. In the main appsettings.json file, I specify my desired environment:

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "ActiveEnvironment": "Development"
}

In Program.CS, I then build an IConfiguration, and set the environment name to the value of the 'ActiveEnvironment', before loading the environment specific configuration file.

public static void Main(string[] args)
{
    WebHost.CreateDefaultBuilder()
    .ConfigureAppConfiguration((hostingContext, config) =>
    {
        // Get the environment from our hostContext.
        var env = hostingContext.HostingEnvironment;
        config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);

        // Build an initial configuration.
        IConfiguration Configuration = config.Build();

        // Set the environment name.
        env.EnvironmentName = Configuration.GetSection("ActiveEnvironment").Value;

        // Load the configuration file for our specific environment.
        config.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true)
        .AddEnvironmentVariables();
    })
    .UseStartup<Startup>()
    .Build()
    .Run();
}

Obviously, when publishing to different environments, the 'ActiveEnvironment' needs to be changed accordingly.

@Swazimodo

This comment has been minimized.

Copy link

@Swazimodo Swazimodo commented Oct 26, 2017

@DaleMckeown I was going to do something similar but I had a question about your implementation. I see you are using the Microsoft.AspNetCore.WebHost to create the default configuration. Does this approach still apply for a console application with no web components?

@DaleMckeown

This comment has been minimized.

Copy link

@DaleMckeown DaleMckeown commented Oct 26, 2017

@Swazimodo I haven't tried this solution int the context of a console application, so I'm not sure. Best bet its to see if there is an alternative way to setting the environment variables for console applications.

@gsmits

This comment has been minimized.

Copy link

@gsmits gsmits commented Oct 26, 2017

@ThisNoName

This comment has been minimized.

Copy link

@ThisNoName ThisNoName commented Nov 4, 2017

It seems all solutions require some kind of post build/publish tweaking? I ended up dropping an empty text file in the app root and pass that in as environment. Did I miss anything?

@evil-shrike

This comment has been minimized.

Copy link

@evil-shrike evil-shrike commented Nov 16, 2017

Totally agree with the first post. It's by design pretty flexible but at the end it's turned out to be very hard to automate. For example I have an app which I publish to IIS on another server. Also it runs on local IIS (via folder publish). So I set Development environment in web.config. But then I need to change it onto Production or whatever during publishing. Pretty common task I guess. I believe it's impossible, right? I have to manually edit web.config on remote servers.

Ideally setting Environment should be supported via "dotnet publish" (for any publish target):

dotnet publish ... -environment=Production

dotnet publish could search for web.%Enviroment%.config (Web.Production.config, Web.Development.config) files and merge (transform) it with web.config. At the end we'd have correct value of ASPNETCORE_ENVIRONMENT:

	<environmentVariables>
		<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="value passed to publish" />
	</environmentVariables>			
@nil4

This comment has been minimized.

Copy link

@nil4 nil4 commented Nov 16, 2017

@evil-shrike have a look at https://github.com/nil4/dotnet-transform-xdt for build/publish time config transforms.

@jeremycook

This comment has been minimized.

Copy link

@jeremycook jeremycook commented Jan 26, 2018

A use case, perhaps. I need logs to be written to .\App_Data because my application runner has read/write access to everything under .\App_Data, but can only read everything else under .\ . I use web deploy, and would like to be able to deploy a web.config like this one with the logs folder under App_Data:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\<assembly>.exe" stdoutLogEnabled="true" stdoutLogFile=".\App_Data\logs\stdout" />
  </system.webServer>
</configuration>

You might ask, why not just put those settings in a web.config file instead of web.release.config? Well processPath=".\<executable>.exe" is not where the executable lives when I'm developing locally against IIS Express. So I get the good ol' "HTTP Error 502.5 - Process Failure" error.

@jefraim

This comment has been minimized.

Copy link

@jefraim jefraim commented Jan 27, 2018

We automate our builds using Jenkins and our existing way of doing vars configuration per environment in NetFramework projects is through web.config transforms. So we thought we will be able to do it in dotnet as well.

It turns out that msbuild is still compatible with aspnet core csproj for doing web.config transforms!

We can add the TransformXml publishing task in the Asp.Net Core csproj:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

Add the specific transform targets:

<Target Name="ConfigDev">
    <TransformXml Source="web.config" Transform="web.dev.config" Destination="web.config" /></Target>

Do some transformations, for example on the ASPNETCORE_ENVIRONMENT variable in the web.dev.config:

<system.webServer>
    <aspNetCore processPath="dotnet" arguments=".\Test.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" >
      <environmentVariables>
        <environmentVariable xdt:Locator="Match(name)" name="ASPNETCORE_ENVIRONMENT" value="dev" xdt:Transform="SetAttributes" />
      </environmentVariables>
    </aspNetCore>
</system.webServer>

Transform web.config using msbuild before running publish:

msbuild Test.csproj /t:ConfigDev
@MikeInSwitzerland

This comment has been minimized.

Copy link

@MikeInSwitzerland MikeInSwitzerland commented Mar 9, 2018

"Let me prefix this by saying that I'm no fan of web.config but experience of publishing AspNetCore apps to IIS is really poor."

I couldn't agree more with this thread.

After the simplicity of config transformations in regular ASP.Net, this whole dependency on a machine-wide ASPNETCORE_ENVIRONMENT variable stinks.

Even Microsoft's own examples say we can use, say, an appsettings.Production.json file, just by adding this line...

            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

...but it pays no attention to the NAME of the configuration we've chosen. So even when I have chosen my Production configuration, it'll still try to open appsettings.development.json. And no, I don't want to have to manually edit the ASPNETCORE_ENVIRONMENT variable myself each time I publish to a different environment. That's just asking for trouble.

I've yet to see a simple, working example of using appsettings.XXXX.json files.
I can't wait for this stuff to finally be finished. (Sigh...)

@willapp

This comment has been minimized.

Copy link

@willapp willapp commented Mar 10, 2018

Yes, please fix this!!

I have just deployed my first production dotnet core site, and now face the issue that I can't easily have a staging instance on the same server because I don't know how to publish my app onto the same box without it picking up the production settings.

I think I'm going to try @DaleMckeown solution for now, I think it will work but it does feel like a workaround rather than a solution. Environment variables are great but ONLY if you have a 1-1 ratio of servers to environments, and outside of enterprise I doubt that happens often.

@DaleMckeown

This comment has been minimized.

Copy link

@DaleMckeown DaleMckeown commented Mar 10, 2018

@willapp My suggestion is definitely a workaround. But it does work - I've had multiple versions of the same app running on the same server for a while now and haven't had any issues.

Just remember to change the 'ActiveEnvironment' setting before you publish and you should be fine.

@zinczinc

This comment has been minimized.

Copy link

@zinczinc zinczinc commented May 6, 2018

I am facing exactly what dkent600 mentioned:

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables> 

does not work on production server. The application keeps using "appsettings.Development.json" values, which, ultimately defeats the benefits of xml transformation when publishing.

I will try the workaround suggested by DaleMckeown.

@ThisNoName

This comment has been minimized.

Copy link

@ThisNoName ThisNoName commented May 6, 2018

the only reasonable way to change ASPNETCORE_ENVIRONMENT is using web.config

Not really. If you need to run multiple instances of the same site on the same machine, here's a much simpler way

  • MyCoreSite
    • bin
    • logs
  • env.Whatever

Point your IIS app to bin and in program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

That's it. You can have as many sites as you want, deploy into bin without worrying about transform, and even switch environment by renaming env.Whenver.

@orobert91

This comment has been minimized.

Copy link

@orobert91 orobert91 commented May 10, 2018

I upvote this. I have URL rewrites configured for production server that do not work in the test environment. I have not found a way for publish to select the right web.config file for deployment, I have to copy it manually.

@nil4

This comment has been minimized.

Copy link

@nil4 nil4 commented May 10, 2018

@svallis

This comment has been minimized.

Copy link

@svallis svallis commented Jun 3, 2018

Is there any progress on this? It has been 13 months since the initial report, 2.1.0 is here now, and things are still pretty poor with traditional IIS hosting. Things work wonderfully if you're using Azure, but that's not currently an option for a large portion of the sites I'm hosting.

It seems that for traditional IIS hosting it would be beneficial to set the desired environment on the command line (as @evil-shrike laid out above), and also within any .pubxml publish profiles. As @davidfowl said, it would need to be clear that this would just work using web.config and IIS, but that surely still covers a substantial part of the install base.

At the moment I have a very brittle solution using Microsoft.DotNet.Xdt.Tools and web.config translation, but it requires a build configuration per environment to get working and has just broken after updating to v2.1.0.

It'd be great to hear if there are any plans in this area and, if so, what they are? If there are no plans, or they are a long way off, then surely there's a better interim solution than the brittle/semi-manual ways we are currently forced to employ? Especially for deploying to QA and staging, I'd really like to be able to just press a button in VS and know the right thing is happening, and not have to depend on head knowledge and manual processes.

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented Jun 4, 2018

We don't have any plans currently but this tool https://github.com/nil4/xdt-samples/ by @nil4 looks pretty good.

@svallis have you tried it?

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented Jun 4, 2018

Is the main thing people want to set the environment?

@svallis

This comment has been minimized.

Copy link

@svallis svallis commented Jun 4, 2018

@davidfowl Yeah, my current solution is using the tool you linked, but for a project with multiple destinations to publish to it requires a build configuration per environment. You need the different build configurations in order to have something to latch onto in the csproj setup, and for my purposes it's generally a 1 to 1 relationship with your environments. For example:

  • Build configuration: Debug = Environment: Development
  • Build configuration: Staging = Environment: Staging
  • Build configuration: Release = Environment: Production

For latter two, I then have the corresponding web.{Build configuration}.config and appsettings.{Environment}.json, and the web.{Build configuration}.config is literally just a XDT to tell the web.config to end up with the appropriate ASPNETCORE_ENVIRONMENT environment variable. So for example, continuing the example above, web.Release.config looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <aspNetCore>
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

This actually all works pretty well from the command line. Running dotnet publish -c Staging or whatever produces a folder with the correct output and the web.config transformed as required. It does feel like it could be simplified though. If there was an -iisenvironment switch on dotnet publish which did this for us, and then that was exposed as a simple text box in VS publishing, it would remove the need for managing build configurations, XDTs, etc manually for traditional IIS hosting situations.

From within VS it currently seems problematic, though. I won't go into the details yet as I'm still trying to pin down where my issues are exactly, as we're still working through the conversion from v2.0.0 to v2.1.0 and it's possible the problems I'm having are unrelated to this. We're currently unable to publish from within VS at all though, and even when it did work on v2.0.0 we had to manually select the correct build configuration before publishing. We've reverted to publishing via the command line for the time being, but this is far from ideal. Ignore this, the problems I'm having in VS seem unrelated to this, so I'll create a new issue for that if I can reproduce it in a test repo.

@wggley

This comment has been minimized.

Copy link

@wggley wggley commented Jul 31, 2018

@vijayrkn could you please elaborate more on using pubxml?
I upgraded my SDK to 2.1.302 (x64) changed my pubxml but cannot see any difference on web.config published.

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Aug 1, 2018

@wggley - The fix is not available in 2.1.302. It should be available in the next upcoming release.

You can try the preview version of the cli containing the fix from here - https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Let me know if you run into any issues with the above preview version.

@wggley

This comment has been minimized.

Copy link

@wggley wggley commented Aug 1, 2018

Thanks @vijayrkn I'll wait for next upcoming release and try to use on a new publish.
I would like to point that @frankhoffy solution worked for me like a charm:
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Look for first answer (most voted answer).

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Aug 23, 2018

Web config transform support during publish is now available in 2.2 preview1 https://www.microsoft.com/net/download/dotnet-core/2.2

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented Aug 23, 2018

@vijayrkn is there a basic sample somewhere? It would be great to point people to the hello world equivalent using a basic transform that sets ASPNETCORE_ENVIRONMENT.

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Aug 23, 2018

To set ASPNETCORE_ENVIRONMENT, users can set the msbuild property '$(EnvironmentName)'. I will add a sample that shows how to set other env variables using web.config transforms.

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Aug 24, 2018

Here is a sample repo - https://github.com/vijayrkn/webconfigtransform

Readme has details on how this works:
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

Hope this helps!

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Aug 28, 2018

@Eilon - We can close this issue. This is fixed and available in the latest preview.

@Eilon Eilon closed this Aug 28, 2018
@nmg196

This comment has been minimized.

Copy link

@nmg196 nmg196 commented Sep 25, 2018

@vijayrkn It's not clear how to configure the Publish settings to set the environment from the Publish settings dialog? What actually can be changed in this dialog to distinguish a Staging site from a Production site, if both sites are being deployed to the same server?

This aspect of .NET core seems very messy. It needs to be made much easier to specify the environment on a per-folder basis. A whole-server environment variable cannot work for our situation at all. Not everyone can run their staging sites on different servers to their production sites.

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented Sep 25, 2018

The setting is per application.

@nmg196

This comment has been minimized.

Copy link

@nmg196 nmg196 commented Sep 25, 2018

Sorry but that doesn't really answer my question. Perhaps I'm misunderstanding something.

@davidfowl

This comment has been minimized.

Copy link
Contributor

@davidfowl davidfowl commented Sep 25, 2018

There's some pseudo documentation here https://github.com/vijayrkn/webconfigtransform/blob/master/README.md (@vijayrkn we need to get this into the real docs).

@vijayrkn How much support is there for this in the publish dialog?

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Sep 25, 2018

Currently the publish dialog does not have any support for setting the publish environments but the environments can be set manually in the publish profile or specific transforms can be applied.

@nmg196 - If you want to just set the 'ASPNETCORE_ENVIRONMENT' in the web.config, all you have to do is add the environmentname to the publishprofile.

example:
https://github.com/vijayrkn/webconfigtransform/blob/master/Properties/PublishProfiles/FolderProfile.pubxml#L18

For advanced scenarios (other than setting the ASPNETCORE_ENVIRONMENT environment variable) web.config transforms can be applied as mentioned in the documentation above.

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Sep 25, 2018

@davidfowl - Angelos has an item to get the web.config transform support documented.

@xuyae573

This comment has been minimized.

Copy link

@xuyae573 xuyae573 commented Oct 25, 2018

@vijayrkn How to use in CI/CD of TFS? I couldn't use the dotnet publish with p:CustomTransformFileName in TFS

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Oct 25, 2018

You can pass this msbuild property to dotnet publish.

You can refer to this sample here - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

This passes the CustomTransformFileName property to dotnet publish

dotnet publish /p:Configuration=Release /p:EnvironmentName=Staging /p:CustomTransformFileName=custom.transform

@stephenarsenault1

This comment has been minimized.

Copy link

@stephenarsenault1 stephenarsenault1 commented Nov 6, 2018

@vijayrkn
I have read your documentation and cannot get the web.config to transform. I've tried basically all of the commands you have in the readme.md and none of them result in the transformation being performed.

I have however been able to write a powershell script which uses Microsoft.Web.XmlTransform.dll to perform the transformation separate from the publish operation.

My question is what version of msbuild and dotnet are you using?
I am using:
dotnet --version 2.1.104
dotnet msbuild -version 15.6.84.34536

Thanks

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Nov 6, 2018

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Nov 19, 2018

@davidfowl wrote:

There's some pseudo documentation here https://github.com/vijayrkn/webconfigtransform/blob/master/README.md (@vijayrkn we need to get this into the real docs).

@vijayrkn How much support is there for this in the publish dialog?

Do you know whether this was ever added to the real docs, if so do you have the link please ?

ryanbrandenburg pushed a commit that referenced this issue Nov 27, 2018
@DM2489

This comment has been minimized.

Copy link

@DM2489 DM2489 commented Dec 11, 2018

We've moved over to using <EnvironmentName> in our publish profiles now. It would be nice to have some UI on top of this so that it is more visible, though. I presume this will come at a later date?

@dmitryshunkov

This comment has been minimized.

Copy link

@dmitryshunkov dmitryshunkov commented Dec 13, 2018

I think it is a breaking change to enable by default web.config transforms on dotnet publish. After installing .NET Core SDK 2.2.101 it broke our CI/CD scenario. Our pipeline configured to create published artifact using dotnet publish only once for any release (build once rule), transformation applied automatically on real deployment (performed by Octopus). I could not found any mention in documentation about this change. Spent a bit of time trying to figure out what the reason for doubled configuration blocks in web.config after deployment. Apparently, transformation was applied twice: by dotnet publish and by release management tool.

After disabling web.config transformations with <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> setting, TransformWebConfig also skipped (along with TransformXml), which results in %LAUNCHER_PATH% and %LAUNCHER_ARGS% variables not being replaced during publish process. Is there a setting to control these steps independently?

@auserx

This comment has been minimized.

Copy link

@auserx auserx commented Dec 21, 2018

Does this work in a console app with the App.Config file?

Can we see an example?

@vijayrkn

This comment has been minimized.

Copy link

@vijayrkn vijayrkn commented Dec 21, 2018

@dmitryshunkov you can set $(RunXdt) to false to just skip running the custom Xml tranform.

@auserx - if it is an sdk style project, then it should work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.