-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try out new .NET 6 logging generator #32087
Comments
I asked @maryamariyan to give it a try. I think there are some issues that will prevent full adoption but we should I aim to move. cc @gfoidl |
If @maryamariyan's try succeedes I'd like to broaden that usage here (this generator seems really cool). |
Thanks for contacting us. |
I made a quick test with the logging generator and it looks very promising, so I believe we can use that for some logging that needs to written new or to be rewritten (like the Kestrel trace). |
Looking forward for this. Let me know if you are looking for help. |
ATM there are two (?) points that should get addressed before we can use the logging generator:
|
Thanks for the quick reply! Is it worth removing the help wanted label here and add it to the linked issues if/when appropriate? |
Opened this issue dotnet/runtime#52549 to list up logging generator related issues. Not all need to be addressed right away. @gfoidl I think dotnet/runtime#51927 depends on how we end up with the API review on dotnet/runtime#50913 |
IMO dotnet/runtime#51927 is quite independent from dotnet/runtime#50913. The logging generator can skip the IsEnabled-check if there's a LoggerMessage.Define overload, otherwise (in the fallback case) ignore that "hint" which is merely an optimization. I know that dotnet/runtime#51927 needs to be reviewed too, but when touching the logging for Kestrel, etc. it would be nice that it can be done once and use the goodness from the new logging generator. |
* Update Components to use LoggerMessage Contributes to #32087
Thanks @pranavkm for making a bunch of progress here. Moving to .NET 7 milestone to cover the remainder. |
Updates the Mvc project to use the LoggerMessageAttribute for logging generation. ## Description The following files contained duplicate log event ids which had to be renumbered: - MvcCoreLoggerExtensions - MvcRazorLoggerExtensions - MvcViewFeaturesLoggerExtensions - RazorRuntimeCompilationLoggerExtensions Also fixes a typo in a method name in RazorRuntimeCompilationLoggerExtensions: ViewCompilerInvalidingCompiledFile --> ViewCompilerInvalidatingCompiledFile Contributes to #32087
Updates the Mvc project to use the LoggerMessageAttribute for logging generation. ## Description The following files contained duplicate log event ids which had to be renumbered: - MvcCoreLoggerExtensions - MvcRazorLoggerExtensions - MvcViewFeaturesLoggerExtensions - RazorRuntimeCompilationLoggerExtensions Also fixes a typo in a method name in RazorRuntimeCompilationLoggerExtensions: ViewCompilerInvalidingCompiledFile --> ViewCompilerInvalidatingCompiledFile Contributes to dotnet#32087
* Use LoggerMessageAttribute in more places * Servers * Antiforgery * Missed Blazor and Security projects Contributes to #32087
MvcCoreLoggerExtensions includes the log messages for a whole slew of MVC types. Consequently it re-uses event ids and is hard maintain. This PR simultaenously updates the type to use LoggerMessageAttribute, while also attempts to move as many of the individual log statements to the appropriate type. This change unearthed incorrect reuse of event ids within the same type that has also been corrected by assigning new ids. Fixes dotnet#32087
MvcCoreLoggerExtensions includes the log messages for a whole slew of MVC types. Consequently it re-uses event ids and is hard maintain. This PR simultaenously updates the type to use LoggerMessageAttribute, while also attempts to move as many of the individual log statements to the appropriate type. This change unearthed incorrect reuse of event ids within the same type that has also been corrected by assigning new ids. Fixes #32087
.NET 6 has a feature to generate logging classes from attributes. Could reduce the amount of boilerplate in our logging types while also validating log event IDs aren't duplicated.
See dotnet/runtime#36022
We should try replacing some small static Log types with the new feature.
The text was updated successfully, but these errors were encountered: