如何在NLog中将日志记录器名称限制为枚举或指定结构？

Great question! This is a common pain point when using NLog (or any logging library) — relying on string literals for logger names leads to avoidable typos and inconsistent categorization. Here's a clean, maintainable solution that keeps your existing cross-project NLog configuration intact:

Step 1: Define an Enum for Valid Logger Categories #

First, create an enum that lists all approved logger names. This gives developers a dropdown of valid options in their IDE and eliminates typos at compile time:

public enum LoggerNames
{
    Thermal,
    Database,
    Api,
    Ui
    // Add additional categories as your project grows
}

Step 2: Build a Static Helper Class #

Wrap NLog's native LogManager.GetLogger method in a static helper that accepts your enum instead of a string. This acts as a single, controlled entry point for logger creation:

public static class NLogHelper
{
    // NLog caches loggers internally, so no need to add extra caching logic here
    public static ILogger GetLogger(LoggerNames loggerName)
    {
        // Convert the enum value to its string representation
        return LogManager.GetLogger(loggerName.ToString());
    }
}

Optional: Custom Logger Names with Enum Descriptions #

If you want logger names that differ from the enum's identifier (e.g., "DatabaseOperations" instead of "Database"), use Description attributes to map enum values to custom names:

using System.ComponentModel;

public enum LoggerNames
{
    [Description("ThermalSystem")]
    Thermal,
    [Description("DatabaseOperations")]
    Database
}

public static class NLogHelper
{
    public static ILogger GetLogger(LoggerNames loggerName)
    {
        var fieldInfo = loggerName.GetType().GetField(loggerName.ToString());
        var descriptionAttribute = fieldInfo.GetCustomAttribute<DescriptionAttribute>();
        // Fall back to the enum name if no description is set
        var loggerNameString = descriptionAttribute?.Description ?? loggerName.ToString();
        
        return LogManager.GetLogger(loggerNameString);
    }
}

Step 3: Update Logging Calls #

Now developers use the helper class with the enum, which provides compile-time safety and intellisense:

// Valid: Compile-time checked, no typos possible
NLogHelper.GetLogger(LoggerNames.Database).Debug("Error writing to DB");

// Invalid: Won't compile (no such enum value), so typos are blocked
// NLogHelper.GetLogger(LoggerNames.Datobuse).Debug("...");

Why This Fits Your Scenario #

• Preserves Cross-Project Configuration: Since we're still using NLog's native LogManager, your single configuration file will continue to work across all projects in your solution — no extra setup required.
• No Need to Rewrite NLog: You don't have to modify or hide NLog's static LogManager class; the helper simply wraps it cleanly.
• IDE-Friendly: Developers get auto-completion for valid logger names, making it faster and easier to pick the right category.

Extra: Enforce Usage with Code Analysis #

To prevent accidental use of LogManager.GetLogger directly, add a Roslyn analyzer (or use tools like StyleCop) to flag raw calls and suggest using your helper class instead. This adds an extra layer of enforcement for consistent logging practices.

内容的提问来源于stack exchange，提问作者Dave