If you want your deployment process to be idempotent, I would suggest using this deployment step for installation in Azure Web App.
https://marketplace.visualstudio.com/items?itemName=pascalnaber.PascalNaber-Xpirit-WebAppConfiguration
Technically, it adds release settings to web.config, which is not necessary for the main application, but, importantly, it also sets the environment variables for the Azure host.
If you indicated that you are using environment variables in Startup.cs:
public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) .AddEnvironmentVariables();
So, if you have the variable release: appsetting.ASPNETCORE_ENVIRONMENT = Release, you will find that $ env: ASPNETCORE_ENVIRONMENT will really be "Release" if you check the PowerShell console on Kudu.
I really use this extension to override all my appsettings.json variables as well as ASPNETCORE_ENVIRONMENT at release time, rather than tokenzing some appsettings settings. {environment} .json. I can simply override environment variables using the correct naming convention in my VSTS Release Variable names.
For example, if my appsettings.json has this structure:
{ settings: { secret: { foo: "bar" } } }
I can override the release variable, for example:
appsetting.settings: secret: foo = "bar"
Then go to check $ env: settings: secret: foo in Azure Web App after deployment
Without doing anything extra in my source or removing the web deployment package, tokenizing the configuration file, and then re-looping to msdeploy, I have environment-specific settings.