VSTS Task to deploy AppSettings and ConnectionStrings to an Azure WebApp

The Azure WebApp Configuration task reads VSTS variables and adds those as AppSettings and ConnectionStrings to an Azure WebApp. The task also supports Slot Settings. The task can be linked to a web.config to validate if all AppSettings and ConnectionStrings in the web.config exists as VSTS variable.

Task can be found in the marketplace and added to your VSTS account. The code is open source and can be found on GitHub.

Naming convention

The task uses naming conventions in the VSTS variables to deploy appsettings and connectionstrings to an Azure WebApp. If you like as a Slot Setting. The value of the VSTS variable is used for the value for the appsetting or in case of a connectionstring, the connectionstring.

The following naming conventions rules are supported:

  • The name of a variable for an appsetting must start with appsetting.
  • The name of a variable for a connectionstring must start with connectionstring.
  • The type of database should be added in the namingconvention as stated in the following table.
  • For a slotsetting the convention .sticky must be used.

The table below shows some examples:

Type Example VSTS variable name
appsetting appsetting.mysetting
appsetting with slotsetting appsetting.mysetting.sticky
connectionstring to SQL Server connectionstring.myconnectionstring.sqlserver
connectionstring to SQL Azure connectionstring.myconnectionstring.sqlazure
connectionstring to custom connectionstring.myconnectionstring.custom
connectionstring to MySQL connectionstring.myconnectionstring.mysql
connectionstring with slotsetting connectionstring.myconnectionstring.sqlserver.sticky

Steps to use and configure the task

  1. Install the task in your VSTS account by navigating to the marketplace and click install. Select the VSTS account where the task will be deployed to.
  2. Add the task to your release by clicking in your release on add a task and select the Utility category. Click the Add  button on the Apply variables to Azure webapp task.
  3. Configure the task. When the task is added the configuration will look like this:
    All yellow fields are required.
    – Select an AzureRM subscription. If you don’t know how to configure this. Read this blogpost.
    – Select the web app name.
    – Select the resourcegroup.
    – If you want to deploy to a Deployment slot, check the Deploy to Slot checkbox and select the Slot.
    – If you want to validate the VSTS variables against the appSettings and ConnectionStrings in the web.config of the application you deploy, then select the web.config. Otherwise uncheck the Validate variables checkbox.
    – When you want validation, you can choose how the task should behave when it finds incorrect variables. Default behavior is that the task will fail with an error. This results in a failed Release  and the variables will not be deployed.
    The other validation result action is  to only get a warning. The variables will be deployed to Azure.
    – By default all existing AppSettings and ConnectionStrings in Azure are overwritten by the variables in the release. When you don’t want this, but you want to preserve your appsettings or connectionstrings in your WebApp, then uncheck the Overwrite existing configuration checkbox.
  4. The web.config of your application is not being used to deploy variables to Azure. If you have configured validation, the keys of the appSettings and the names of the ConnectionStrings are used to validate if there are VSTS variables available for these settings. The web.config in this sample looks like this:
  5. Add variables that match the names of the variables in the AppSettings and ConnectionStrings. Also apply the namingconventions for the VSTS variables.
  6. Instead of configuring Release variables as in step 5, you can also configure Environment variables. This step shows you how you can configure the release in VSTS to support multiple environments. In this sample each environment will have the same appsettings and connectionstrings. But the value of those differentiate.
    After creating the Environments, configure variables per environment. Just like step 5, just add the keys and the values. ConfigureVariablesPerEnvironment
    To see the Environment variables at a glance, select the Environment variable view as you can see in the following picture:
    When you have configured all Environments, you will see an overview like the following:
  7. When you run the release, the settings will be deployed to Azure. In this sample it looks like this:
    Note that the hidden value in VSTS is visible now in Azure.

15 gedachtes over “VSTS Task to deploy AppSettings and ConnectionStrings to an Azure WebApp

  1. This is great. We were in the middle of developing something ourselves (but not quite as clean as this). This is one item missing off the standard list of tasks that Microsoft should really be supplying. The only thing that we are missing (which we now script separately is enabling of websockets).

    Liked by 1 persoon

    • Thanks. This task does not change the web.config. It’s updating appsettings and connectionstrings in Azure. So if you like your webjob to make use of these Azure AppSettings and Connectionstrings, you have to update the code in the WebJob. Make use of CloudConfigurationManager instead of ConfigurationManager. Like: CloudConfigurationManager.GetSetting(“mysetting”). Does this help you?


  2. This is great, the only thing I cannot work out is how to manage settings that differ across environments.

    My first environment could be a test environment that uses different databases to the others, the others may be regional deployments where some settings as common and some are environment specific.

    Do you have a pattern for solving this?


    • Thanks Philip,
      The solution for your problem is to use Environment variables instead of Release variables.

      The release variables can be accessed by clicking on variables in Release.
      Environment variables can be accessed by clicking the Environment of your choice and select “Configure Variables”.

      Though all Environment variables can be seen by clicking on variables in the Release and than click on Release variables at the right. Now you can select Environment variables.

      Does this help you?


  3. Currently this fails for Azure Functions settings with following error: ##[error]Exception calling “AddRange” with “1” argument(s): “Value cannot be null.
    I’ve validated that you can set app settings using powershell, so I’m not sure what’s the underlying issue is.


  4. Hi Pascal

    Nice work by the way I have a question, How do i update one of the appsettings with pre-defined variables?
    I would like to have an appsettings called “ReleaseVersion” and i want to update that value with pre-defined variable $(Release.ReleaseName)

    any hint to achieve this scenario?



    • Actually, i got this error :
      ##[error]Exception calling “AddRange” with “1” argument(s): “Value cannot be null.

      Do you know the cause of this error ?
      Thank you


  5. Hi,

    Quick question, if we have a single release that deploys say a front end and back end web app is there a way we could have this in a single Release and assign some app.settings to say back end and some to front end?




Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )


Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s