LoggerMessage organisation
Looking for some insight in how people using SG logging organise their methods.
Do you have them inside the class?
disadvantages: have to make all classes that use logging partial (although maybe that isn't so bad), and also I like the ext method syntax more
or do I just accumulate a static
Log
class for extension methods
I like the ext method here but there is no way to separate the logging methods and make them private, so I can see the code completion getting huge and naming collisions becoming a problem6 Replies
I've seen both approaches used in grep.app
https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/csharp/Client.Core/src/HubConnection.Log.cs
https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching/src/LoggerExtensions.cs
and yeah it's preference at the end of the day, just wondering what other people's preferences are and why
for the in-class one, you can also leave off the logger parameter
and it will use the class member
though not sure if it will pick up primary ctor parameters
very interesting
unfortunately the generator kind of died
GitHub
LoggerMessage source generator does not work with logger from prima...
Description The source generator for LoggerMessage does not work if the logger is injected from the primary constructor. Reproduction Steps Create the project. dotnet new classlib dotnet add packag...
this actually doesn't sound too too hard to fix 👀 maybe I will look (and get proven wrong)