LoggerMessage: Why So Difficult?

[stbychkov]

Hi guys,

I've created a source generator (NuGet package) to automate the creation of LoggerMessage calls in .NET projects. After dealing with too much boilerplate using your approach, I built this solution to generate everything automatically with minimal setup from the user.

Problem

Writing repetitive boilerplate code for every log statement is tedious, especially in larger projects with thousands of log calls.

Solution

My solution scans the entire codebase and automatically generates logging methods for all log calls, requiring no additional attributes or manual method creation. It works quite fast even in midsize projects with over 2k+ log statements. For very large projects, further optimization can be explored.

Conclusion

I believe this approach is more user-friendly, as it keeps the same interaction with the ILogger class and eliminates the need for redundant method definitions. I hope you find this approach valuable and would consider adding it to the core. If you'd like help with contributing, feel free to reach out to me.

[davidfowl]

This is very cool use of interceptors! I think the only downside to this approach is that you don't get to treat the log message like a contract (the log level and the event id are not coupled to the logger message, but instead reverse engineered from the call site). If you wanted to make sure that log messages were versioned with similar rigor to public API how would you go about doing it with this approach?

[stbychkov]

Thanks for the comment!

I think the main limitation comes from the LoggerMessage source generator expecting static event IDs in the method declaration. Maybe I missed the reasoning behind this decision, but in my opinion, event IDs should work more like passing a dynamic log level. If a user provides a log level, we pass the given value to ILogger.Log/Define method instead. The same logic should apply to eventIds - you should be able to set any static or dynamic eventIds outside of the source generator. A hardcoded value in the attribute doesn't help in this scenario.

So if you want to log different messages based on some conditions (like versioning), it should just be a matter of making a few ILogger calls with different log levels or event IDs.

Like I said earlier, the current approach feels a bit hacky, and eventId is no exception, it can be done better for sure.

P.S.: I agree that this is a nice way to use interceptors, but if Microsoft.Extensions.Logging supported generic log methods (and why not?), we wouldn’t need interceptors at all. It’d also make setup a lot simpler for developers and decrease the minimum supported target framework at least to net6.0.

[stbychkov]

So continuing the discussion, with this fix it's possible to version logger messages dynamically based on the LoggerExtensions.Log* invocation.

if (isSupported) {
    logger.LogInformation(new EventId(1, "Event 1"), "Event happened");
} else {
    logger.LogInformation(new EventId(2, "Event 2"), "Event happened");
}

vs

if (isSupported) {
   LoggerMessages.LogEvent1(logger);
} else {
    LoggerMessages.LogEvent2(logger);
}

public static partial class LoggerMessages
{
    [LoggerMessage(Level = LogLevel.Information, Message = "Event happened", EventId = 1, EventName = "Event 1")]
    public static partial void LogEvent1(ILogger logger);

    [LoggerMessage(Level = LogLevel.Information, Message = "Event happened", EventId = 2, EventName = "Event 2")]
    public static partial void LogEvent2(ILogger logger);
}

Let me know if I missed addressing your question or if further clarification is needed.