## 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