Azure-functions-host: Application settings not available from local.settings.json in Azure, but available locally in Visual Studio

[hansmbakker]

My appsettings from local.settings.json were not available in Azure.

My settings were put in local.settings.json. I only put the settings I wanted to override in the Azure Portal since I want to have the common settings in version control.

It turned out that the settings from the Azure Portal were available, but the ones that were not overridden (that should be loaded from local.settings.json) were not available.

Expected behavior

I expect Azure to read the settings from local.settings.json first, and then override them with values defined in the portal.

Actual behavior

In the remote Azure environment the local.settings.json settings were not available (ConfigurationManager.AppSettings["FromAddress"] returned null for a setting called FromAddress defined in the Values section of the json file.

They are available locally in Visual Studio.

Known workarounds

Define all the settings in the Azure portal, even the ones that are the same for local development and Azure

Related information

• I use VS 2017 15.3 Preview 2.0 with Functions Tools for VS 2017
• I develop a precompiled C# Azure Function

[thusnjak]

I wouldn't expect LOCAL settings to be available in Azure. :)

Your workaround is actually the expected behaviour - please someone correct me if I'm wrong.

[hansmbakker]

It is just confusing as for other App Services types it IS normal to have a file with settings (app.config / web.config) that contains the default values, which can be overridden in the Azure Portal. Also, the local.settings.json file is deployed to Azure. I expect it to read it.

[ahmelsayed]

/cc @fabiocav

[paulbatum]

Its very deliberate that the local.settings.json file is not honored. in fact it is not even supposed to be uploaded to your function app because it is likely to have connection strings in it. Unfortunately this means there is no good equivalent of a web.config file today for functions. We plan on addressing this as part of our porting work to .NET core.

[benjamin-goldman]

so basically this means that integrating azure functions into existing CI/CD pipelines is a show stopper for most MS centric shops.

[paulbatum]

@bgoldman69 I'm not sure what you mean, can you elaborate? My CI/CD setups use ARM templates to deploy the function apps with the appropriate app settings. These ARM templates are in source control and have CD hooked up so when I need to add a new app setting I just commit the changes to the ARM template.

[suprak]

What is the process by which the local.settings.json settings should be published to Azure Portal from VS?
Currently the VS publish process ignores these settings.

[thusnjak]

AFAIK none - you have to write/edit your settings on Application settings via Azure portal manually before you publish your function app (at least that's how we do it, but we don't change these settings often so it is not a problem).

[alemag1986]

Hey MS team, I'm trying to debug an azure function triggered by the service bus, not long ago, I was able to run the function locally on VS Preview 15.3; Now I'm running VS Enterprise 15.3.2 and I keep getting:

"Missing value for AzureWebJobsStorage in local.settings.json. This is required for all triggers other than HTTP. You can run 'func azure functionapp fetch-app-settings ' or specify a connection string in local.settings.json."

My local.settings.json is the current directory as well is being copied to debug folder.

[sabbadino]

same for me .. in a chatbot project , and I couldn't have the local.settings.json read

[sabbadino]

Regarding not having a web.config equivalent for function projects ..
this is a very big pain .. we have streamlined our delivery pipeline for web apps on different environments using configuration files and config transforms
.. and now we should move to arm templates parameters file to get the same result when using Azure Functions projects instead of azure web app projects ..

I hope that soon azure functions can read settings from a json file (ok xml is no more sexy enough)
and that something like this
https://github.com/Microsoft/json-document-transforms/wiki
for json transform will be supported in vsnet

enrico

[alemag1986]

Hey @sabbadino I just opened a new ticket about this issue here: 213

[andreasbotsikas]

@thusnjak have you seen https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local#publish ? I haven't tested but seems to publish the settings.

I have been updating the portal app settings using an arm template.

You can deploy an ARM template from your powershell using New-AzureRmResourceGroupDeployment like this:

$ResourceGroupName = "MyResourceGroupWhichWillContainTheAzureFunction"
New-AzureRmResourceGroupDeployment -Mode Incremental  -TemplateFile azureFunctionTemplate.json -ResourceGroupName $ResourceGroupName -fnName "functionName" -username "myUsername" -password "some secret"

Another option is to use the -TemplateParameterFile and have all the parameter values in a json file.

All parameters will be picked up by the ARM Template and you can set the appSettings section of the ARM template like the following:

{
  "$schema": "http://schemas.management.azure.com/schemas/2015-01-01-preview/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "fnName": {
      "type": "string"
    },
    "username": {
      "type": "string"
    },
    "password": {
      "type": "string"
    }
  },
  "variables": {
    "functionAppName": "[parameters('fnName')]",
    "hostingPlanName": "I can hardcode staff here",
    "location": "[resourceGroup().location]"
  },
  "resources": [
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2015-04-01",
      "name": "[variables('hostingPlanName')]",
      "location":  "[variables('location')]",
      "properties": {
        "name": "[variables('hostingPlanName')]",
        "computeMode": "Dynamic",
        "sku": "Dynamic"
      }
    },
    {
      "apiVersion": "2015-08-01",
      "type": "Microsoft.Web/sites",
      "name": "[variables('functionAppName')]",
      "location": "[variables('location')]",
      "kind": "functionapp",
      "properties": {
        "name": "[variables('functionAppName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
      ],
      "resources": [
        {
          "apiVersion": "2016-03-01",
          "name": "appsettings",
          "type": "config",
          "dependsOn": [
            "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
          ],
          "properties": {
            "FUNCTIONS_EXTENSION_VERSION": "latest",
            "WEBSITE_CONTENTSHARE": "[toLower(variables('functionAppName'))]",
            "WEBSITE_NODE_DEFAULT_VERSION": "6.5.0",
            "BackendUsername": "[parameters('username')]",
            "BackendPassword": "[parameters('password')]"
          }
        }
      ]
    }
  ]
}

[ransagy]

So basically, When working with just the Azure Functions SDK/tooling you don't persist app settings/connection strings in source control at all?

Two developers working on the same function would need to somehow externally coordinate which settings are required for the function to run? (ARM template, looking at a deployed copy in the portal in the App Settings blade, etc)

[paulbatum]

Correct, you generally want to avoid putting connection strings and other keys/secrets in source control. You can source control an ARM template with non sensitive app settings and then have your deployment system inject the necessary secrets when deploying.

[davidhagg]

Our Octopus server handles the transforms of secrets and connection strings so they are not in source control. The behavior differs from how other Microsoft products do it, and that is a pain.

[MisinformedDNA]

I agree that we shouldn't be checking in secrets, but local.settings.config isn't just secrets. Some settings are added just to avoid hard-coded values in code. By adding local.settings.json to .gitignore (or just choosing not to check it in), we make it difficult for the next developer to pick it up and start debugging locally. They either have to recreate the JSON file, have it emailed from a previous developer or otherwise manage these files. This was a problem recently when our code was handed off to the support team; when they needed to make their first change, nothing would run because they had no local.settings.file.

This problem doesn't exist in CI/CD, but CI/CD isn't used to set up a dev environment.

[davejhahn]

I wouldn't expect to deploy the ARM template when deploying a specific application that that is hosted in the resource group. I look at the ARM template as the configuration for the resources in a resource group, not application specific information that the resources contain. Each time I deploy a web app, I don't deploy the ARM template only the web app (unless there is a change to the resource group itself, which would be a separate package and deployment). I treat these as totally separate things and separate repos.

[sabbadino]

Totally 100% agree

[bluebirdtech]

Given the lack app.config style configuration, we've worked around it by deploying a settings.json file to the root of the function app and manually reading it, e.g.

var settingsPath = Path.Combine(executionContext.FunctionAppDirectory, "settings.json");
dynamic settings = JsonConvert.DeserializeObject(File.ReadAllText(settingsPath));
var myConfigValue = (string)settings.Values.MyConfigValue;

This allows us to do transformation on deployment using Octopus. Possibly adds a little overhead, but working fine for our needs.

Not having a local.settings.json file didn't seem to be an issue.

[ElliotSchmelliot]

[Jun 19, 2017] ...there is no good equivalent of a web.config file today for functions. We plan on addressing this as part of our porting work to .NET core.

@paulbatum Any updates on some sort of web.config equivalent for functions being addressed?

[MisinformedDNA]

@ElliotSchmelliot You can add and read from any file you want as described above by @bluebirdtech. What specific scenario are you still unable to workaround?

[ElliotSchmelliot]

@MisinformedDNA I was just curious if adding a function config file as a standard was still in the pipeline. This thread is by far the most documentation I've found on the subject.

If you're curious about my specific scenario, I have nearly identical functions across three deployments (dev, test, prod) that I am trying to consolidate into one. When deploying, a few function values need to be transformed per that specific deployment. The solution from @bluebirdtech may work for most cases, but does not allow me to dynamically change the name of the function.

For the moment, I'm using preprocessor directives to replace this info based on build configurations:

#if azuredev
    [FunctionName("DevFunction")]
#elif azuretest
    [FunctionName("TestFunction)]
...

I'm using the above linked SO post to document the possible solutions for this issue for my own sake and hopefully to the benefit of others. That being said, I would love to see some official documentation on the subject.

[BowserKingKoopa]

Any update on this? This issue should not be closed. We need an "app.config" for Functions.

[MisinformedDNA]

@BowserKingKoopa I added a new issue for removing local.settings.json and replacing it with appsettings.json: https://github.com/Azure/azure-functions-host/issues/3189

[Porkechebure]

Is this a joke or real life?
Get your ** togheter.
Aside the local.settings.json which I understand that is for local developement, there is a host.json file.

From what I read around that would become, once published, the azure function version of "App.config" file.

In fact, if i publish my function to my azure portal subscription account, and under the Function app settings tab of the azure functions app services list, I find the deployed "host.json" file with all the configuration I've put in it, but no matter what I use, I can't read from it.

The file is right there, online and reachable.

Tried

ConfigurationManager.Appsettings["key"]

and

System.Environment.GetEnvironmentVariable("MYCONFIG", EnvironmentVariableTarget.Process);

as suggested in microsoft guide and it was a total fail. Everything is null.

Are you kidding me?

And don't even bring in the "you shouldn't share secrets". What if I just put some generic configuration in there? MaxConcurrentCalls, MaxConnectionAttempts or whatever you like???

Give us a solution

For now the only way to do it seems to add them as Application settings under the menu of the function app with the same name.

If it is so, what the hell the host.json file is for? Just adding some spice to a developer life?

[ahmelsayed]

Open a new issue for your question, also share share which guide is telling you to put settings in host.json and then read them from ConfigurationManager. That was never the case.