Destructuring operator doesn't work about serilog-extensions-logging

[alecor191]

That's great news! Looking forward to your decision.

BTW I updated in a similar way SerilogLoggerProvider.Enrich(), specifically the following line

var property = propertyFactory.CreateProperty(keyValue.Key, keyValue.Value);

That allows me to write code like:

var foo = ... // some object
var myLogValues = new MyLogValues(); // Implements ILogValues
myLogValues.Add("@Foo", foo); // Use destructuring parameter

using (logger.BeginScope(myLogValues))
{
    logger.LogInformation("Some message");
}

This way I can attach destructured objects to my logging messages in cases where I don't want them to be part of the message template (essentially get a similar behavior as with ForContext()).

[nblumhardt]

Doing some build work so dropped this change in; @alecor191 did you find the null-check necessary in:

if ((property.Key != null) && (property.Key.StartsWith("@")))

? I left it off since I think it'd probably violate the intentions if not the contract of ILogValues to return null for the key, but if you hit it in practice it'd be great to know.

Thanks again for the suggestion!

[nblumhardt]

Thanks for the feedback. M.F.L doesn't actually support Serilog directly; the {Named} argument support is provided natively by M.F.L and so only the features it provides work with its pipeline.

Are you writing a web application, or middleware? If you are building an app, using Serilog directly is the best bet. There are options to get structured data through M.F.L but they're a bit more involved, happy to help.

[alecor191]

Hi @nblumhardt. Thanks for your reply. I'm working on both middleware and web apps and I would like my assemblies to all depend on the same logging framework (M.F.L.).

I understand that Serilog comes with some additional features that M.F.L doesn't provide. About the specific limitation mentioned above, I did a quick POC: Essentially replace the following line in SerilogLogger.cs (where it iterates through structure.GetValues())

logger = logger.ForContext(property.Key, property.Value);

with the following

if ((property.Key != null) && (property.Key.StartsWith("@")))
{
    logger = logger.ForContext(property.Key.Substring(1), property.Value, true);
}
else
{
    logger = logger.ForContext(property.Key, property.Value, false);
}

This will result in the following behavior: When a '@' destructing argument is used in a message template, it will destruct the provided object (like when used directly with Serilog APIs)

What are your thoughts? Would this be something you could consider adding to the project as well?

[nblumhardt]

Hi @alecor191 - that's very interesting - thanks for digging in deeper!

Definitely a strong proposal; I can't see too many issues with the approach (perhaps a very slight performance hit in the general case caused by StartsWith()), but let me think through it just a fraction more carefully.

Looking good though!

[trreeves]

@alecor191 Also at the moment you can achieve the same thing by doing:

using (logger.BeginScope("{@Foo1} {@Foo2} ignored", foo1, foo2))
{
    ...
}

'ignored' will not be logged.

[trreeves]

The destructuring feature in Serilog does look particularly useful, and it seems a shame for it not to become available with MFL.

So from a purist point of view, as MFL doesn't support the destructuring concept, it looks a little 'leaky' to have '@'s in the message format; switching to a different logging provider means you end up with lots of properties starting with an '@' that you didn't have previously.

My current project is a large ASP.NET 5 based product, where customers have the freedom to customise it in every way, so although we will ship with a default logging implementation (probably Serilog), our application code will only be dependent on MFL for all the obvious reasons.

At the moment, I think I am OK with going with the '@' approach. The only alternatives I can think of are less desirable, short of persuading Microsoft to support complex properties...

[nblumhardt]

@trevorreeves thanks for the notes!

@alecor191 I'd like to move forward on this incrementally; let's make the first change (support for @ in message templates) and see how we go with that. I'm less sure about the second suggestion, since although Serilog does provide destructuring for enriched properties, the API is semantically different (not based on @ template holes).

Would you be interested in creating a PR against dev for the change?

[alecor191]

Hi @nblumhardt. Sorry for the late reply. I didn't run into a scenario where the null check would be necessary. I just added it in my prototype.

Thanks a lot for including this change!

[nblumhardt]

Thanks for the follow-up @alecor191 - cheers!

[nblumhardt]

Published: https://www.nuget.org/packages/Serilog.Framework.Logging/1.0.0-beta-4

[wlo023]

Hi @nblumhardt. I know this is a pretty old issue, but I wanted to see if there was any more thought given to possibly supporting destructuring of objects in BeginScope? As @alecor191 mentioned, it is handy in providing functionality similar to ForContext(). Or is there better way to do that within MEL?

Thanks!

[nblumhardt]

Hi @wlo023 - I think the MEL way to do it (which Serilog supports) is just to pass a dictionary:

BeginScope(new Dictionary<string,object>{["Foo"] = "Bar", ...})

Does this cover what you're thinking of?

Cheers!

[wlo023]

@nblumhardt - that does work for simple values (i.e. string, int, etc) but for complex objects, it just does a "ToString()" on the object when I really want it to destructure the object.

i.e.

using (BeginScope("{@user}", new User { FirstName = "John", LastName = "Smith"})

I would only get ".User" as the value of "user" in the log.

I think this is because in the SerilogLoggerScope.cs, the Enrich method has these lines:

 var property = propertyFactory.CreateProperty(stateProperty.Key, stateProperty.Value);
 logEvent.AddPropertyIfAbsent(property);

with destructureObjects always set to the default of false. I think a similar trick to what was suggested before with the messages and checking if the key starts with "@" and then passing the correct boolean value for destructureObjects would do it.

One of the overloads for BeginScope is:

public static IDisposable BeginScope(this ILogger logger, string messageFormat, params object[] args)

That is pretty similar to the API for logging a message, so to me, it would seem to make sense to support the destructuring operator in the messageFormat.

If you agree, I can volunteer to create a pull request with the changes and unit tests.

Thanks!

[nblumhardt]

I see, yes, we should accept @ in this overload.

using (BeginScope("{@user}", new User { FirstName = "John", LastName = "Smith"})

The corresponding LOC is:

https://github.com/serilog/serilog-extensions-logging/blob/dev/src/Serilog.Extensions.Logging/Extensions/Logging/SerilogLoggerScope.cs#L61

PR happily accepted, thanks 👍

[neman]

Just a simple question, so in MEL, since there is no Serilog ForContext correlation concept the recommended approach is to use BeginScope.

[wlo023]

Correct - it seems that the closest analogue for ForContext is the BeginScope functionality