org.sonar.plugins.csharp.S6672.html Maven / Gradle / Ivy
Why is this an issue?
In most logging frameworks, it’s good practice to set the logger name to match its enclosing type, as enforced by {rule:csharpsquid:S3416}.
Logging frameworks can define or use Generic interfaces for the
logger, such as ILogger<TCategoryName>.
The use of a logger of a generic type parameter A (e.g. ILogger<A>) in a type different than A, say
B, goes against the convention.
Because the instance of type A would log with a logger named after B, log items would appear as if they were logged by
B instead, resulting in confusion and logging misconfiguration:
- overriding defaults for the logger named after
A would not take effect for entries logged in the type A
- fine-graned logging configuration would not be possible, since there would be no way to distinguish entries logged in the type
A
from entries logged in the type B
Further details and examples are provided in {rule:csharpsquid:S3416}.
This rule specifically targets the generic logging interface ILogger<TCategoryName> Interface
defined by Microsoft Extensions Logging.
How to fix it
Change the generic type parameter of the ILogger interface to match the enclosing type.
Noncompliant code example
class EnclosingType
{
public EnclosingType(ILogger<AnotherType> logger) // Noncompliant
{
// ...
}
}
Compliant solution
class EnclosingType
{
public EnclosingType(ILogger<EnclosingType> logger) // Compliant
{
// ...
}
}
Resources
Documentation
- Microsoft Learn - .NET logging and tracing
- Microsoft Learn - Generic interface
- Microsoft Learn -
ILogger<TCategoryName> Interface
- Microsoft Learn - Logging in C# and
.NET - Log category