How to publish environment specific appsettings in .Net core app?

Question

I have 3 environment specific appsettings files in my .Net core application

in project.json I have setup publishOptions like this. ( based on suggestion here)

"publishOptions": {
    "include": [
      "wwwroot",      
      "appsettings.development.json",
      "appsettings.staging.json",
      "appsettings.production.json",
      "web.config"
    ]
  },

I have 3 corresponding startup classes that uses appropriate appsettings based on environment

var builder = new ConfigurationBuilder()
    .SetBasePath(env.ContentRootPath)
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true);

However when I publish the application then all 3 appsettings files end up in all environments. How do I publish environment specific appsetting file?

Keever

Can someone please answer this question. It really doesn't make sense to publish all appsettings.json files to all the environments. – Keever

As long as you host on Windows, you'll be fine, but if you switch to a case-sensitive OS (*nix), you'll be in trouble. E.g. MS's EnvironmentName strings are PascalCased. – Heartland

Did you find any solution to this? I'm using asp.netcore 3.1 – Slipper

not really. Currently my powershell script copies the whole publish folder and then deletes unwanted appsettings. Note that even if you don't delete appsettings your application is not going to use all. Your application will only use appsettings.json and appsettings.{environmentname}.json. The order in which you are loading files at startup is important here – Keever

I get so tired of all the fundamental features that are left out of .NET Core, makes it hard to take serious. – Tennietenniel

Answer 1

If someone else is wondering how to use different appsettings for multiple environments here is a possible solution.

dotnet publish --configuration [Debug|Release] will copy the appropriate appsettings.json file into the publish folder if *.csproj has a conditional logic for these files:

• First in the .pubxml publish profile file (can be found in Properties->PublishProfiles of Visual Studio) disable that all content files are included by default

<PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <EnableDefaultContentItems>false</EnableDefaultContentItems>
</PropertyGroup>

• Then specify conditional Debug/Release logic

<Choose>
    <When Condition="'$(Configuration)' == 'Debug'">
      <ItemGroup>
        <None Include="appsettings.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
        <None Include="appsettings.prod.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
      </ItemGroup>
    </When>
    <When Condition="'$(Configuration)' == 'Release'">
      <ItemGroup>
        <None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
        <None Include="appsettings.prod.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
      </ItemGroup>
    </When>
</Choose>

• Finally inside Startup.cs try to load both files

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

    Configuration = builder.Build();
}

I hope this solution, has been helpful.

Enter

Does not answer question as asked. – Graphics

I think it does answer as asked. Each environment, when published to, gets only the relevant appsettings file. – Slapdash

@Ben, this answer actually has to be marked as an answer! It worked for me like a charm! – Exactitude

good to know approach but does not answer the question as it clearly states publishing for different environments like staging, production, dev, etc, but this answeer tries to solve the question using configuration. – Kiri

There is just a little problem with this answer: your appsettings.xyz.json must contains all the property of the original one but that's not how it's working for the configuration pattern. Luckly the solution is pretty easy! First of all, register the appsettings.json as first file and then register all the others envrionment's specific files. After that you can modify the logic on your .csproj to always include appsetting.json and only one of the others environment specific based on the configuration/environment name – Microscope

Answer 2

I recently had to find a solution for this as well and I accomplished it by adding some settings to the .csproj file and a minor change to Program.cs.

<Project Sdk="Microsoft.NET.Sdk.Web">
    <!-- ... -->
    <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
        <DebugSymbols>true</DebugSymbols>
        <DebugType>full</DebugType>
        <DefineConstants>DEBUG;TRACE</DefineConstants>
        <EnvironmentName>Development</EnvironmentName>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
        <DebugType>pdbonly</DebugType>
        <Optimize>true</Optimize>
        <EnvironmentName>Production</EnvironmentName>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Stage|AnyCPU'">
        <DebugType>pdbonly</DebugType>
        <Optimize>true</Optimize>
        <EnvironmentName>Staging</EnvironmentName>
    </PropertyGroup>
    <ItemGroup>
        <Content Remove="appsettings.json" />
        <Content Remove="appsettings.*.json" />
    </ItemGroup>
    <ItemGroup>
        <Content Include="appsettings.json" CopyToOutputDirectory="PreserveNewest" />
        <Content Include="appsettings.*.json" Exclude="appsettings.$(EnvironmentName).json" DependentUpon="appsettings.json" CopyToOutputDirectory="Never" />
        <Content Include="appsettings.$(EnvironmentName).json" DependentUpon="appsettings.json" CopyToOutputDirectory="PreserveNewest" />
    </ItemGroup>

    <Target Name="RenameAppsettings" AfterTargets="Publish">
        <Move SourceFiles="$(PublishDir)\appsettings.$(EnvironmentName).json" DestinationFiles="$(PublishDir)\appsettings.overrides.json" />
    </Target>
</Project>

To explain it a little, I added an <EnvironmentName> element for each configuration so it can be used during the build process. I'm using appsettings.{EnvironmentName}.json (i.e. appsettings.Staging.json) just as an "overrides" file so I just have it rename the necessary JSON file during the build process. When you run dotnet publish -c Stage, for example, it will publish the appsettings.Staging.json file into the publish folder and rename it to appsettings.overrides.json. In your Program.cs, you will just need to include the appsettings.overrides.json file as well:

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

I hope it helps!

Side note: I include appsettings.*.json and set it to CopyToOutputDirectory="Never" just so they still show up in Visual Studio when developing. Otherwise, if you only want the current environment's appsettings file to show in VS, just remove that line from the csproj file.

Ithunn

I tried your solution and it works beautifully except that I'm publishing to a specific folder using "--output c:\temp" and my appsettings.json is correctly ending up in $OutputPath which (I guess) is the staging area for the publish (netcore2.1/win-x64) but doesn't get copied to the final publish folder. Any ideas how I can access that --output destination folder? The publish folder is getting both the appsettings.json AND appsettings.Staging.json and not the result from my Move. – Amongst

Hmm, I'm not sure I'm following exactly. It should still publish the correct result to the --ouput path that you specify. Are you expecting a single appsettings.json file in the output directory? With the solution I posted, you will always have 2 appsettings files. One being appsettings.json and the other being appsettings.overrides.json. It should be taking your "override" settings (i.e. from appsettings.Staging.json) and renaming it to appsettings.overrides.json in the output directory. Perhaps you can post what you're doing as a question and I can help find an answer? – Ithunn

There seem to be 2 important folders during publish. One is the bin/..win-x64 folder and the second is the publish folder (if I don't use --output the publish folder is created under win-x64). My appsettings are correct in the win-x64 but not in the publish. If I could figure out the symbol (like $OutputPath) that points to the publish folder I'd just move directly there, but I haven't been able to find that one. I have hard coded the Move and it's working, but there must be a way to do this correctly. – Amongst

Ah, I see. The value for getting the publish dir is $(PublishDir). You should be able to replace $(OutputPath)\publish in the solution I gave with $(PublishDir) and it should do what you're looking for. I've also updated the answer to use $(PublishDir) instead as well because it's better to use that so it can support --output. Thanks for bringing it up! – Ithunn

I should have guess that! I was searching for a complete list of symbols and when I didn't see one I just punted and hard-coded it temporarily. Thank you so much!!! – Amongst

@Ithunn I've tried your solution and all works well locally. However, when deployed to the server there's an error "The configuration file 'appsettings.Development.json' was not found and is not optional" even though I specified the "Testing" environment in the publish? – Erich

@Erich Does your Program.cs contain the setting of optional: true for appsettings.{env.EnvironmentName}.json? i.e. .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true) It should be renaming your {env.EnvironmentName}.json (appsettings.Development.json in your case) to appsettings.overrides.json as defined in the <Target Name="RenameAppsettings" AfterTargets="Publish">... configs. Your Program.cs file will only be reading in/looking for appsettings.overrides.json when it's deployed. – Ithunn

I like this answer but have hit an issue. VS 2019 .met core 3.1. During a "publish" it looks for appsettings..json and errors out. I am not sure what to do about that. – Carpophagous

Answer 3

The simple solution is to specify the environment name in publish configuration file (.pubxml). So that you don't need to add it to the Environment Variable and you can host apps with multiple configurations on the same server.

<EnvironmentName>{Enviornment name}</EnvironmentName>

The application will use the corresponding appsettings.json file after publishing it. You can see all the .json files after the publication, but the app will use only the Enviornment settings value.

Rooster

I used this when I was facing the issue and then next time, it stopped working. – Swanger

tried this and on publish I just got all 3 appsettings.*.json files copied, I was expecting that only 1 will be copied – Xanthochroid

Does not answer the question being asked. – Browne

This did not work for me either. It used Production, event though I set EnvironmentName to Staging. – Interpellant

Answer 4

You can use MSBuild conditions to optionally include files in the compilation output (or published output).

<ItemGroup Condition="'$(Configuration)'=='Release'">
  <Content Remove="appsettings.Development.json;appsettings.Staging.json" />
  <None Include="appsettings.Development.json;appsettings.Staging.json" />
</ItemGroup>

The above ignores the Development and Staging appsettings.json file variants when the compilation target configuration is Release.

Credent

Answer 5

In my case I have several appSettings files for several live environments, e.g. appSettings.Env1Live.json, appSettings.Env2Live.json, etc.

I looked through the article https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-3.1 and added the following statements in the corresponding publish (pubxml) config files per each environment.

E.g. for PublishToEnvironment1.pubxml added:

<ItemGroup>
<Content Update="appsettings.*Live.json" CopyToPublishDirectory="Never" />
<Content Update="appsettings.Development.json" CopyToPublishDirectory="Never" />
<Content Update="appsettings.Env1Live.json" CopyToPublishDirectory="PreserveNewest" /></ItemGroup>

So, in the published folder I have only two necessary files, other appSettings.*Live.json were not published.

appsettings.json

appsettings.Env1Live.json

Prober

This works and is simple and straight froward - I think it should be the accepted answer. – Underfeed

Answer 6

You need to actually add the environment variables, according the official tutorial:

var builder = new ConfigurationBuilder()
    .SetBasePath(env.ContentRootPath)
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true)
    // do not forget to add environment variables to your config!
    .AddEnvironmentVariables();

Digester

Answer 7

In VS2017 Adding multiple environment

steps right click project --> Add --> NewItem - select json file - write file name as 'appsettings.staging.json' or 'appsettings.production.json'

School

But it only works if i run the solution localhost. When publish, the environment is always production no matter what I set up in propertis (launch.json) :/ any Idea ? – Attire

@Attire you need to set the ASPNETCORE_ENVIRONMENT variable to eg Staging. It defaults to production. – Daradarach

@Anders Emil Actually, when publishing to IIS, the environment variable is taken from the web.config and not from the environment property of the project. – Attire

Answer 8

Consider you have multiple appsettings: dev,pre,prod. You can have below configuration in your web project file.

         <!-- This configuration is done for dotnet publish command.
     It will make sure only environment specific files will be copied -->
          <ItemGroup Condition=" '$(EnvironmentName)' == 'Dev'">
            <Content Remove="appsettings.Prod.json" />
            <Content Remove="appsettings.Pre.json" />
          </ItemGroup>
          <ItemGroup Condition=" '$(EnvironmentName)' == 'Pre'">
            <Content Remove="appsettings.Prod.json" />
            <Content Remove="appsettings.Dev.json" />
            <Content Remove="appsettings.Development.json" />
          </ItemGroup>
          <ItemGroup Condition=" '$(**EnvironmentName**)' == 'Prod'">
            <Content Remove="appsettings.Pre.json" />
            <Content Remove="appsettings.Dev.json" />
            <Content Remove="appsettings.Development.json" />
          </ItemGroup>
        

This configuration will help during publish. It will not copy the appsettings which is not required for that environment.

EnvironmentName (part of ) highlighted above should be passed as parameter in below command.

        dotnet publish -o ../../published/20191118A -c release /p:EnvironmentName=Development

Pallas

Answer 9

I have this same problem because I need to switch between different production configuration files due to multiple sites using the same codebase.

In the end, I created a powershell script for each client/site. The script copies a client-specific configuration file over the production configuration file, then runs the publish. I actually do this for both the appSettings.json file and the environment.ts file. The script looks a bit like this:

Remove-Item –path ClientApp\src\environments\environment.prod.ts
Remove-Item –path appsettings.production.json
Write-Output "--> config files removed"
Copy-Item -path ClientApp\src\environments\environment.CLIENT-SITE-NAME.ts ClientApp\src\environments\environment.prod.ts
Copy-Item -path appsettings.CLIENT-SITE-NAME.json appsettings.production.json
Write-Output "--> config files copied"
dotnet build MYPROJ.csproj -c Release /p:DeployOnBuild=true /p:PublishProfile=CLIENT-SITE-NAME 
Write-Output "--> built & published"
Remove-Item –path ClientApp\src\environments\environment.prod.ts
Remove-Item –path appsettings.production.json
Write-Output "Finished"

In each of my client sites' .pubxml files, I exclude ALL the non-production appsettings from being published, like so:

<ItemGroup>
  <Content Update="appsettings.json" CopyToPublishDirectory="Never" />
  <Content Update="appsettings.site1.json" CopyToPublishDirectory="Never" />
  <Content Update="appsettings.site2.json" CopyToPublishDirectory="Never" />
  <Content Update="appsettings.development.json" CopyToPublishDirectory="Never" />
</ItemGroup>

I remove the production files in the end to make sure I don't accidentally deploy them to the wrong site using the Publish wizard.

(I store the password in the pubxml file, but you could include it in the script as a parameter as an alternative)

Ironsides

Answer 10

I tried below configuration in .csproj. I have three Application json file for each environment (Development, Staging, Production). I have updated the .csproj file based on the Environment Variable

<ItemGroup Condition="'$(EnvironmentName)' == 'Development'">
    <Content Update="appsettings.Production.json" 
CopyToPublishDirectory="Never"/>
    <Content Update="appsettings.Staging.json" 
CopyToPublishDirectory="Never"/>
</ItemGroup>

<ItemGroup Condition="'$(EnvironmentName)' == 'Staging'">
    <Content Update="appsettings.Production.json" 
CopyToPublishDirectory="Never"/>
    <Content Update="appsettings.Development.json" 
CopyToPublishDirectory="Never"/>
</ItemGroup>

<ItemGroup Condition="'$(EnvironmentName)' == 'Production'">
    <Content Update="appsettings.Staging.json" 
CopyToPublishDirectory="Never"/>
    <Content Update="appsettings.Development.json" 
CopyToPublishDirectory="Never"/>
</ItemGroup>

Hope this works for everyone.

Mancino

By far the simplest solution. – Browne

Answer 11

One possible way would be to run prepublish or postpublic scripts/commands, for example by running an gulp task executing dotnet publish-iis (alternatively use a task in prepublish section of scripts to copy the files to the before publishing.

Add this to your project.json:

"scripts": {
  "postpublish": [ "gulp cleanconfig", "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}

You can also run a cmd or shell command here. But actually there shouldn't be any reasons why you would want to do this in the first place, just ship all 3 appconfig files, because on i.e. Azure App Service, you can switch the mode depending on the environment variables which is regulated via the Azure Portal and when publishing, the staging and production slots will be just swapped, but the environmental variables stay.

You shouldn't store secrets within the appsettings.json though (which I assume you doe and the reason you want to remove the files). Instead, use "user secrets" for development and environmental variables to set connection strings etc. for production. Works like a charm, especially with Azure App Services and docker containers.

Borglum

I don't have any secrets in appsettings. However we do have connection strings in appsettings which is different for each environment. I think its perfectly okay to have connection string in appsettings. I really don't understand why I have to jump through hoops to publish environment specific appsettings. In fact that should be the standard behavior of publishing process. I don't think anyone wants all appsettings files endup in all the environments.. I think we are missing something here.. – Keever

Well, if the connectionstring has user name and password or an api key in it, it's a secret. if it doesn't then, it also doesn't hurt to publish all 3 files. What's the exact matter? – Borglum

It does not have userid/password. Also its irrelevant to the question what data actually appsetting file contains – Keever

Tseng is correct in this, at the generic level you should have something in your toolchain remove the files you do not want in the published results, be it gulp,grunt, powershell whatever that executes at post build/pre deploy – Digitigrade

Finally i ended up using Powershell script to copy files. In the script i have logic to copy appsetting file based on environment. – Keever

Even just revealing how many environments you have, and their names, is a security risk, and lazy. I think the root cause here is VS should simply remove the others when it knows which environment it is publishing for. – Browne

@MarkWorrall That's just paranoia. Neither knowing the environments nor the contents of the appsettings is a security risk. The appsettings.json isn't meant to hold secrets. And especially if creating containers, one doesn't know in which environment it runs until the container is started. The real security happens by proper design, not by obscurity. Security by obscurity (and "hiding environments" configs is obscurity) is no security at all – Borglum

And visual studio can't and won't know where you publish, its not VS tasks in general. Most companies build in the build pipeline and either store the artefacts and publish them in their release pipelines or containerize the application, both cases which aren't really compatible with your proposal or crease more headache that its worth or you lose determinism by rebuilding your project for each environment. Just put no secrets into it and you are good to go. Usually you also dont need more than the 3 default environments: production, develpoment and testing which is hardly a secret ;) – Borglum

Lot of systems I have worked on security would not allow files that are not actually needed to be deployed, however big a headache it was. Also large project often have 5 or more environments: Dev, Integration Test, System Test, UAT, Staging, Prod, and sometimes Prod Mirror and others (Demo, etc). – Browne

Yea, but that's not an issue with setting files themselves, its an issue with the personal responsible for security who have bad or no understanding security at all. Don't blame the tool for ignorance of people. Also not sure what you use your appsettings.json for, but you usually don't put any critical stuff in there. Mostly logger settings (unless you have your own centralized provider, such as azure key value store etc). most common use case for appsettings is for local development, test pipeline and one settings for rest (production) – Borglum

And mostly like to set different folders where stuff is put or removed from, or set service addresses for your rest clients and stuff. you don't put overly dynamic settings in there, since depending on how you deploy/publish it its hard to change afterwards. so most of the other environments dont matter – Borglum

Answer 12

I solved this question with this nuget package: https://github.com/Microsoft/slow-cheetah/blob/master/doc/transforming_files.md

It`s so easy for installation and using all configurations in Active solution configuration (In my case - I added a new "Test" configuration for test deployment).

After this you can install this extension in VS: https://marketplace.visualstudio.com/items?itemName=vscps.SlowCheetah-XMLTransforms.

Just now you can create a new config subfiles for .xml or .json application configuration settings in VS by this tool (as in manual). For example, I has Debug, Test, Release files (appsettings.Debug.json and etc.)

Next step - setting up the publish profiles for each configuration and after publishing you will have only one file with all the necessary transformations.

Transformations works like a classic .json envinronment transormation in .net core web applications.

Natoshanatron

Answer 13

Updated for versions using .csproj

First, in the .csproj file, add the following to ensure the appsettings.json is included in the publish directory during publish.

  <ItemGroup>
    <None Include="appsettings.json" CopyToPublishDirectory="Always" />
  </ItemGroup>

Then update Startup.cs to include:

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

        Configuration = builder.Build();
    }

Swec

Answer 14

To use different appsettings.json depending on the publish profile (i.e. having 2 Azure publish destinations, Development & Production) for Dotnet 7:

1. Create appsettings.(environmentname).json files for each your different publish profiles. e.g. appsettings.Development.json, appsettings.Production.json

2. In your publish profiles (the .pubxml files in Properties\PublishProfiles), specify the publish profile name as the Environment name (eg. Development or Production) by adding an EnvironmentName in the PropertyGroup:

   XML format in the pubxml file is as follows:

    <PropertyGroup>
    <EnvironmentName>Production</EnvironmentName>
    </PropertyGroup>
   

3. By default asp.net core will load the appsettings.(environmentname).json file. (more on this here)

   4. To test which environment you are in, you could use the following code:

      Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ??
      Environment.GetEnvironmentVariable("DOTNET_ENVIRONMENT") ?? "Production";
      

(This is based on this Microsoft document)

Allisan

The question was how to stop appsettings.<environment>.json files being published for other environments to the one being published. – Browne

Answer 15

This work for me:

1. Create 1 pubxml file per appsettings..json file Example: appsettings.PROD.json - profile-prod.pubxml

2. Each pubxml file must contain the following, this means only copy the appsettings.json and appsettings..json that are necesary. This example is for my "prod environment". you do the same for all the others environments.

    <ItemGroup> <Content Update="appsettings.json" CopyToPublishDirectory="Always" />
    <Content Update="appsettings.PROD.json" CopyToPublishDirectory="Always" />
</ItemGroup>

3. Make sure ALL your appsettings.json files are marked as "not copy to output / publish directory"

Resume: As all yours *.json are denied to be copied into the publish directory, when you execute your publish profile, only the ones explicity listed in the pubxml are copied to the publish directory.

Spoilsport

Answer 16

The easiest way i have found so far is to deploy all config files and then remove extra files after the deployment is finished. Just add few extra lines at the end of your deployment shell or batch script.

Waadt

Answer 17

Go to Program.cs after that add WebApplicationOptions

var webAppOptions = new WebApplicationOptions()
{
    Args = args,

#if PRODUCTION
    EnvironmentName = Environments.Production,
#elif STAGING
    EnvironmentName = Environments.Staging,
#elif DEVELOPMENT
    EnvironmentName = Environments.Development,
#else
    EnvironmentName = Environments.Development,
#endif

};
var builder = WebApplication.CreateBuilder(webAppOptions);

Sefton

This has nothing to do with the question – Browne

How is it not related to the question?? It is the best solution for this question. – Sefton

The question was asking all 3 appsettings files end up in all environments., it was about publishing. e.g. they dont want `appsettings.Development.json' published to the Test output when publishing for Test, etc. – Browne

Answer 18

Honestly I think that is not the right task for a build pipeline. Also the publishing features of the dotnet cli are very limited. Go to external tools like Tseng showed you. Deployment is another domain with an own set of complexity than building.

There is not a build in way on dotnet cli beyond using external tools!

Oxidase