Enable web.config transforms for AspNetCore projects in VS

[oliverjanik]

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:

• How to set environmental variable ASPNETCORE_ENVIRONMENT in IIS in the latest ASP.Net Core 1.0? #1701
• http://stackoverflow.com/questions/41546943/how-to-set-aspnetcore-environment-to-be-considered--for-publishing-an-asp-net-cor
• http://stackoverflow.com/questions/43054050/set-aspnetcore-environment-within-build-configuration
• http://stackoverflow.com/questions/39238850/how-to-set-aspnetcore-environment-in-publish-file
• http://stackoverflow.com/questions/38761617/net-core-set-environment-variable-in-azure-deployment-task
• http://stackoverflow.com/questions/40535782/how-to-pass-aspnetcore-environment-variable-to-a-gulp-task-in-vso-build-template

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

@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]

@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]

We took care of this in a different way. We setup our build agent to take the environment specific settings file and overwrite the root settings file with it. Our build makes a separate zip file for each environment that we deploy to.

…

On Thu, Oct 26, 2017 at 12:48 PM, Dale Mckeown ***@***.***> wrote: @Swazimodo <https://github.com/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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2019 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25> .

[ThisNoName]

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]

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]

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