Azure functions: Read config from host.json after deploy

Question

I've made an azure function in C#. I use local.settings.json for testing locally. Everything works correctly with

ConfigurationManager.Appsettings["key"]

Now I have published it. Nothing is working anymore. Host.json is there, I can browse the function app settings tab and I can see the configuration host.json right there with all the values.

Host.json format is the same as local.settings.json:

{
  "IsEncrypted": false,
  "Values": {
    "MYCONFIG": "HEY",
    "THEOTHERCONFIG" : "WHASSUP"
  }
}

If I run locally everything is working fine. If I publish I get null in all the values.

I tried

    ConfigurationManager.Appsettings["key"]

and

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

Nothing works.

Microsoft documentation doesn't unveil the sacred secret of reading a config file.

Here I see they don't even mention a host.json file, they just say you have to manually put them in the azure portal.... which is higly impractical.

Any suggestion? Thank you

you need to put your config in the appsettings blade of the azure functions (portal) — Thomas, Aug 17 '18 at 01:41

Tom Sun - MSFT · Accepted Answer · 2018-08-17T09:33:45.717

4

Settings in the local.settings.json file are only used by Functions tools when running locally. By default, these settings are not migrated automatically when the project is published to Azure. We could use the Azure Functions Core Tools to publish the local.setting.json to Azure easily.

func azure functionapp publish azurefunctionname --publish-local-settings

The host.json metadata file contains global configuration options that affect all functions for a function app.

host.json is not for config Azure function appsettings.

Or as Thomas mentioned that you could config it in your appsettings blade of the azure function.

Update:

If you want to delegate some developement and testing you have to give them credentials... how ridiculous

You could use the Key vault and Azure function MSI to avoid sharing your credentials.

edited Aug 17 '18 at 09:33

answered Aug 17 '18 at 05:46

Tom Sun - MSFT

24,161
3
30
47

Well, it seems the only way. No config file, everything online. If you want to delegate some developement and testing you have to give them credentials... how ridiculous – Liquid Core Aug 17 '18 at 08:33
`If you want to delegate some developement and testing you have to give them credentials... how ridiculous`. You could config credentials in the azure function appsetting on the azure portal to avoid sharing your credentials to other people. Or you could use keyvault and [Azure function MSI](https://learn.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity) to avoid sharing your credentials. – Tom Sun - MSFT Aug 17 '18 at 09:29
@TomSun Is it possible to put my custom settings in host.json file and use that? – Turbo Apr 25 '19 at 23:46
Thanks Tom. Your comment `host.json is not for config Azure function appsettings.` is the only reference I could find that states your app should not use this for general configuration options, and use the App settings in the Azure blade instead. – joe May 02 '20 at 17:59

Duck Ling · Answer 2 · 2021-10-21T21:40:36.687

I appreciate that host.json might not be there for configuring appsettings, but just as an answer to the question...

As read in the docs:

When the runtime finds an application setting in the format AzureFunctionsJobHost__path__to__setting, it overrides the equivalent host.json setting

Example. You'd override the below host.json file:

{
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
              "isEnabled": true
            }
        }
    }
}

With appsettings.json/local.settings.json:

{
...
    "Values": {
"AzureFunctionsJobHost__logging__applicationInsights__samplingSettings__isEnabled":"false"
...
    }
}

This means you can dynamically control what's in host.json this way. Not quite an answer to the OPs question, since it's not accessing but overriding, but I think it's a somewhat valid way to control what's in host.json. If it's a good practice, or not - not me to decide :-)

Azure functions: Read config from host.json after deploy

2 Answers2