Serialize objects as JSON (with @ prefix).

[jovnas]

Please mark the type framework used: ASP.NET Core

• Version: 2.1

Please mark the type of the runtime used: .NET Framework

• Version: 4.7.2

Please mark the NuGet packages used: Sentry.AspNetCore

• Version: 2.1.6

---

I suggest adding functionality to prefix log message parameter names with @ to force serialization of parameters as JSON.

Sentry displays objects logged through the ILogger interface by calling ToString on the object. This works well for anonymous objects - since the compiler generates a JSON-like ToString override - but not for "proper classes".

Example:

class TestClass {
    public string TestProp { get; set; } = "Value";
}

_logger.LogError(
    "Test - {@testObj} - {@anonObj}",
    new TestClass(),
    new { SomeProp = "SomeValue" }
);

"Expected" result:
Test - { "TestProp": "Value" } - { "SomeProp": "SomeValue" }
Actual result:
Test - Namespace+TestClass - { SomeProp = SomeValue }

Other logging libraries (like NLog and Serilog) make use of an @ in the parameter name to force serialization of the parameter as JSON.
https://github.com/NLog/NLog/wiki/How-to-use-structured-logging#formatting-of-the-message
https://github.com/serilog/serilog/wiki/Structured-Data#preserving-object-structure

"Workarounds":

• Manually serialize the object as JSON when logging (e.g. _logger.LogError("{obj}", JsonConvert.SerializeObject(obj));)
• Create anonymous object with relevant data (e.g. _logger.LogError("{obj}", new { Val1 = obj.SomeProp, Val2 = obj.OtherProp.SubProp });)

(Original question on Stack Overflow: https://stackoverflow.com/questions/64317618/send-object-as-json-to-sentry-io )

[bruno-garcia]

Let's call it a new feature :)

I have to admit I thought it was built like that in the first place.

[dreadedcoder]

Just moved our logging to Sentry and the fact that this has not been fixed since 2020 is giving me chills. We use the templates with @ throughout our thousands of lines of code and I'm not sure what to do now. I assumed this was a standard and it would just work

[mattjohnsonpint]

@dreadedcoder - Thanks for the feedback. We'll take another look at this.

[mattjohnsonpint]

After reviewing in detail with @SeanFeldman, we found that this isn't something we can easily do ourselves. There are several reasons, but the main one is that most of the types we'd need to work with are internal to Microsoft.Extensions.Logging, and are extensible in ways we can't predict. For example, the approach attempted in #2231 would end up replacing the incoming formatter with our own - which would eliminate the built-in functionality provided by that formatter. Also we looked at replacing or mutating the state containing the properties to format - but TState is not constrained - it can be anything. Even it it's FormattedLogValues (the default type used by most of the logging extension methods) - that's an internal type also.

Ultimately, methods like ILogger.LogError are not extensible in the way we'd need them to be to correctly implement this feature. Microsoft would have to do it themselves.

The good news is, it appears that much of this work has already been implemented for .NET 8. See https://github.com/dotnet/runtime/pull/79038

Thanks.