1

I'm using VSTS 2017 Release Management with a build-once-deploy-many-strategy. My project is a dotnet core-webproject. First I restore/build/test/publish my project with dotnet and then I publish my artifact (a zip).

My build steps

Now I want to deploy this build with different configurations to different environments. With "regular" dotnet I used WinRM Web App Management together with a parameters.xml to add my environment-specific configuration. As example below:

enter image description here

But my package created with dotnet publish is a zip and not a msdeploy-package.

  1. How do I replace the configurations (appsettings.json)?

  2. How can I deploy it to my IIS?

What I've already tried:

First I ran dotnet publish but without the Zip Published Projects-option. This made it possible to easily make my changes i appsettings.json, but instead required me to use a Copy file-operation to do my deploy. This had the downside of IIS locking the files, which in turn required me to write PS-scripts which took IIS offline/online.

I just want to create a package, which can be deployed to several environments and with different configurations. How can I achieve it?

smoksnes
  • 10,509
  • 4
  • 49
  • 74

1 Answers1

1

You don’t need to change appsettings.json. The core project can retrieve data from appsettings.[environment].json file per to ASPNETCORE_ENVIRONMENT environment variable.

So, just set the ASPNETCORE_ENVIRONMENT environment variable in each environment machine only once.

A related thread: VSTS Deploy IIS App winrm and change appsettings.json.

Update:

Regarding sensitive connectionstring, the better way is protecting secrets using Azure Key Vault. A blog about how to use it: Protecting Secrets using VSTS and Azure Key Vault.

You also can encrypt sensitive information (e.g. connectionstring), then decrypt in your code.

Another way is that you can replace the value before build the project (e.g. Visual Studio Build task) in VSTS build/release. Note: if others can access the published artifact or get the build source file (e.g. private build agent), they can get the sensitive information regardless of replacing the value before build or storing in parameters.xml.

starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
  • We already use appsettings.x.json. But then I assume we need to have the settings in source control? – smoksnes Jul 24 '17 at 09:17
  • Also, as a follow-up-question, how do I handle __aspnetcore_environement__ if there are several environments on the same server? – smoksnes Jul 24 '17 at 09:19
  • 1
    @smoksnes Not clear about settings in source control, what settings? Regarding in same server, no, just a environment in a server. But, you can set environment by using [WebHostBuilder.UseEnvironment method](https://andrewlock.net/how-to-use-multiple-hosting-environments-on-the-same-machine-in-asp-net-core/). (Update the code before build task (e.g. [Replace Tokens task](https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens)) – starian chen-MSFT Jul 24 '17 at 10:00
  • Sorry. With settings I mean my appsettings.json. Let's say that we have a sensitive connectionstring that might not be suitable to have in source control. With the suggested solution I figure that all these must be in source control and known at compile-time? – smoksnes Jul 24 '17 at 10:26
  • @smoksnes The better way is protecting it using Azure Key Vault, check the update of my reply. – starian chen-MSFT Jul 25 '17 at 01:34