Compile-time logging source generator is not compatible with Serilog/NLog

[sakno]

Related issue: serilog/serilog-extensions-logging#197
Many logging providers have support of additional operators and syntactic extensions for message formats. For instance, Serilog allows to use @ operator for the parameter name to inform the logging infrastructure that the actual object must be "deconstructed" instead of serialized just by calling .ToString() method:

var position = new { Latitude = 25, Longitude = 134 };
var elapsedMs = 34;

log.Information("Processed {@Position} in {Elapsed:000} ms.", position, elapsedMs);

It looks like this fact was ignored or just not considered at the time of the feature design. Why? is my first question. Fast time-to-market makes sense, but .NET is not living in an isolation. It's not just a runtime and set of core libraries. It's also a community and tons of popular libraries developed outside of this repo.

As a result, existing users of Serilog cannot use compile-time logging source generator.

/cc @nblumhardt , @snakefoot

The next question: how to fix that?. Here I would like to suggest a few approaches:

• Ignore any characters after { but before parameter name that do not match to variable name rule
• Ignore @ (too specific for Serilog)
• Introduce a special character that can be used in parameter name to skip any check from source generator. For example, it can be ! or ~: "Processed {!@Position} in {Elapsed:000} ms". In this case, the generator will not match Position template parameter with method parameter
• Introduce SkipParametersMatching property in LoggerMessageAttribute attribute

[pinkfloydx33]

Wow. This is definitely disappointing. We just started the process of migrating existing tooling to NET6 and planned to use it for a greenfield application. The logging source generator is one of the features we had hoped to leverage. Unfortunately we use Serilog and rely on the @ "operator" to pump destructured objects into our logging system (Seq). This basically means we either can't make use of the feature or that we would need to mix and match. Not all log messages use such constructs so that's perhaps a viable option... though still unfortunate.

I agree that there should be some way to disable the default behavior, perhaps an additional opt-in value on the attribute that tells the generator to expect custom operators in the template?

Note that Serilog also supports $ which means to forcefully stringify the object. These constructs work in normal log message templates, including logging delegates created manually with LoggerMessage.Define.

See also:
https://github.com/serilog/serilog/wiki/Structured-Data

Collections and dictionaries get destructured by default as well... They're not necessarily just turned into [x.ToString(), y.ToString()]. I'm not sure if that's impacted here or not, but mentioning it just in case.

It would be great if the generator could be updated to handle the above cases, at least in some sort of configurable or opt-in fashion. I imagine it would need to be generic enough to support other logging libraries such as nLog, though I have no clue what they offer. I know that this is all supposed to be general purpose so we can't get provider specific customizations, but custom providers are a large part of the ecosystem. There's got to be something here.

Having the third parties write their own generators could work, but it seems like it'd be overkill (I imagine it'd be a near copy/paste) and I have no clue how that would play with other providers. I should also be able to switch the provider (we are leveraging MS.E.L abstractions after all) without having to worry about whether a generator is offered.

At the very least it would be nice to have some documentation outlining exactly how the generated log methods work under the hood. Perhaps with callouts to some of the more popular features of third party libs that won't work and therefore preclude usage of the generator.

[sakno]

I found related issue in .NET repo: #60968