Support wildcard or regex in minimum level override feature

[StefH]

minimum level override feature required exact case-sensitive match/startswith

Let's assume that I have my own namespaces with different casing, which need both to be logged on Information.

• MyNameSpace
• MYNameSpace

I would like to use it like:

"SeriLog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Default": "Warning",
        "MyNameSpace|MYNameSpace": "Information"
      }
    }
  }

But this is not yet possible: https://github.com/serilog/serilog/blob/master/src/Serilog/Core/LevelOverrideMap.cs#L76-L77

Would it be possible to support wildcard/regex matching here?

[bartelink]

Why would you not have consistent casing, i.e. can you share a bit more about what your complete use case is?

If you can't change it in the source, perhaps doing it as code based config (supply a lambda doing case insensitive comparison) could cover the case?

[StefH]

Hello @bartelink, the main project is using several internal NuGet packages which have a different casing due to legacy. So there are packages starting with MyNameSpace and some with MYNameSpace and for both I want to set the Minimum level to information. The only solution is to add both like:

"SeriLog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Default": "Warning",
        "MyNameSpace": "Information",
        "MYNameSpace": "Information"
      }
    }
  }

However the problem with this is that this solution cannot be used for the configuration for an Azure Function.
(setting the app config setting Serilog__MinimumLevel__MyNameSpace and Serilog__MinimumLevel__MyNameSpace is not accepted because is considered the same)
A lambda for custom case insensitive comparison could help, however I want to control this via the configuration.

So accepting a regex as pattern would be a good option.

[nblumhardt]

I think for this edge case, it's unlikely we'd go to the lengths required to support this feature well. Using a different scheme where Default is Information, and unwanted events identified with rules at Warning, might be a viable workaround (or just generating all events and filtering some out via Filter.ByExcluding(), if all else fails :-))