Cannot create environment variable for logging category with periods

[AnthonyMastrean]

The logging configuration often uses namespaces (or namespace like strings, separated by periods) as category keys.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

The logging and configuration docs agree on creating environment variables for deep configuration structures.

Logging__LogLevel__Microsoft=Information

But, you can't use a period in a variable or environment variable name in any shell that I know of. It's not disallowed by the spec, apparently, but the various shells seem to avoid period in their implementations.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10_02
https://tldp.org/LDP/abs/html/gotchas.html

# Logging__LogLevel__Microsoft.Hosting.Lifetime=Information
bash: Logging__LogLevel__Microsoft.Hosting.Lifetime=Information: command not found

So, how do we do this?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 346bbcf3-9f8e-b253-09fe-906195392783
• Version Independent ID: 0e787ac2-1108-1d94-d62f-ccffa93e06c3
• Content: Logging in .NET
• Content Source: docs/core/extensions/logging.md
• Product: dotnet-fundamentals
• GitHub Login: @IEvangelist
• Microsoft Alias: dapine

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7184a308-a254-9350-a5cd-5bced1f369ae
• Version Independent ID: 726e3bf1-f367-d733-8933-bccc04da0e16
• Content: Logging in .NET Core and ASP.NET Core
• Content Source: aspnetcore/fundamentals/logging/index.md
• Product: aspnet-core
• Technology: aspnetcore-fundamentals
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[adegeo]

@IEvangelist @Rick-Anderson do you have an idea as to the answer? What does the environment variable system use to replace . when the setting contains a .?

[Rick-Anderson]

@serpent5 can probably figure it out.

[serpent5]

The environment variable provider doesn't give special treatment to a .: It only substitutes __ for :. @Rick-Anderson and I looked into this before, but couldn't find a way to make this particular setup work. I can't see that anything has changed here, either.

[IEvangelist]

While this is a good question and fair observation to call attention to it, I do not believe it is a problem. Logging is the only example that I'm aware that has namespaces or various patterns like this within their configuration settings. And since it is logging, there is no real value in keeping it a secret, or securing it away in an environment variable - you know? I'd argue that is should remain in an appsettings.json file.

[AnthonyMastrean]

@IEvangelist fair points... but, we're not supposed to use environment variables for secrets (and that's not the only reason they're used, see DOTNET_ENVIRONMENT and others) and we don't always have an easy way to override or provide an appsettings file (thinking some CI/CD scenarios where your "services" like linked containers syntax is limited).

[IEvangelist]

I was able to set an environment variable locally in my bash environment with this name (based on this SO), it just needed quotes around it:

env "Logging__LogLevel__Microsoft.Hosting.Lifetime=Information"

I confirmed that I see it in the env vars too.

[AnthonyMastrean]

Good find, thanks!

[Rick-Anderson]

Can you set it to

env "Logging__LogLevel__Microsoft.Hosting.Lifetime=Error"

and verify it's working?
Nice work @IEvangelist

[IEvangelist]

Can you set it to

env "Logging__LogLevel__Microsoft.Hosting.Lifetime=Error"

and verify it's working?
Nice work @IEvangelist

I've been testing it a lot this morning (I can confirm that does work), I'm updating the article to also include cross-plat env var setting with notes/link to the SE bits I stumbled upon. See proposed changes here.

[johnwc]

I think this needs to be evaluated again, specifically for apps running in containers. We are not able to set an environment variable that contains a period for a container. So, we are not able to configure logging upon deployment. In our case we only want to turn on Informational logging for a specific library, so not to flood the logs.