VSTS Release Management for .NET Core

1
votes

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?

1
asp.netiisazure-pipelinesazure-pipelines-build-taskazure-pipelines-release-pipeline
How about Azure Key Vault? Does it meet your requirement? - starian chen-MSFT
@starain-MSFT - I'm certain it would work great. But unfortunately I cannot use any cloud services in my current project. And we don't have Azure on-premise either. - smoksnes
You also can encrypt sensitive information and use it in appsettings.json, then decrypt in your code. - starian chen-MSFT

1 Answers

1
votes

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.