NLog.LogManager.Setup() - Introduced LoadConfiguration and friends for ISetupBuilder

[snakefoot]

Very small dive into the idea of fluent-api for setup of NLog-LoggingConfiguration:

LogManager.Setup().LoadConfigurationFromFile();

LogManager.Setup().LoadConfigurationFromFile("NLog.config", optional: false);

LogManager.Setup().LoadConfigurationFromXml("<nlog></nlog>");

LogManager.Setup().LoadConfiguration(nlogConfig);

LogManager.Setup().LoadConfiguration(builder => 
  // Targets where to log to: File and Console
  var logfile = new NLog.Targets.FileTarget("logfile") { FileName = "file.txt" };
  var logconsole = new NLog.Targets.ConsoleTarget("logconsole");
            
  // Rules for mapping loggers to targets            
  builder.Configuration.AddRule(LogLevel.Info, LogLevel.Fatal, logconsole);
  builder.Configuration.AddRule(LogLevel.Debug, LogLevel.Fatal, logfile);
);

This will match the PRs here:

NLog/NLog.Extensions.Logging#418
NLog/NLog.Web#540

This allows one to setup a fallback configuration, if no NLog.config file was found:

LogManager.Setup().LoadConfigurationFromFile().LoadConfiguration(builder =>{
  var config = builder.LogFactory.Configuration;
  if (config != null)
        return;   // Config already assigned and loaded

  // Targets where to log to: File and Console
  var logconsole = new NLog.Targets.ConsoleTarget("logconsole");
            
  // Rules for mapping loggers to targets            
  builder.Configuration.AddRule(LogLevel.Info, LogLevel.Fatal, logconsole);
}));

Or one can so this (Resolves almost #1429, but without autoReload=true support)

LogManager.Setup().LoadConfigurationFromFile().LoadConfiguration(builder => {
   // Dynamically adds the console-target after having loaded from NLog.config
   var consoleTarget = new ColoredConsoleTarget("console");
   builder.Configuration.AddRule(LogLevel.Info, LogLevel.Fatal, consoleTarget);
}));

One can also setup support for loading NLog.config first in Process-Directory (Before NLog5 is released)

var processDir = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule.FileName);
LogManager.Setup().
   LoadConfigurationFromFile(Path.Combine(processDir, "NLog.config"), optional: true).
   LoadConfigurationFromFile();  // Skips loading of default NLog.config if config already loaded

[snakefoot]

Notice no unit-tests yet, because I'm guessing we are entering discussion mode first.

[304NotModified]

This allows one to setup a fallback configuration, if no NLog.config file was found:

LogManager.Setup().LoadNLogConfigFromFile().LoadNLogConfig(builder =>{
var config = builder.LogFactory.Configuration;
if (config != null)
        return;   // Config already assigned and loaded

// Targets where to log to: File and Console
var logconsole = new NLog.Targets.ConsoleTarget("logconsole");

// Rules for mapping loggers to targets            
builder.Configuration.AddRule(LogLevel.Info, LogLevel.Fatal, logconsole);
}));

How does this works if we load from file and enhance it from API? (so it isn't a fallback). And if we do reload, does that work then?

Notice no unit-tests yet, because I'm guessing we are entering discussion mode first.

I think it's nice! Only some naming things I guess

[snakefoot]

How does this works if we load from file and enhance it from API? (so it isn't a fallback). And if we do reload, does that work then?

Notice that the two last code-examples are a little different (fallback when no config):

LogManager.Setup().LoadNLogConfigFromFile().LoadNLogConfig(builder =>{
var config = builder.LogFactory.Configuration;
if (config != null)
        return;   // Config already assigned and loaded (So no need to create fallback config

And the other (enhancing loaded config):

LogManager.Setup().LoadNLogConfigFromFile().LoadNLogConfig(builder =>{
  // Enhances the existing config (Automatically creates new Configuration if none loaded)
  builder.Configuration.AddRule(LogLevel.Info, LogLevel.Fatal, consoleTarget);

Ofcourse with autoReload="true" then all is lost, when enhancing loaded config (reload on file-change will not automatically apply runtime changes). I guess people who are into such exotic scenario will come with some great use-cases and suggestions for how to implement that logic. Much easier to work actual use-cases than trying to predict everything.

Like I said in my introduction of this. Then it is a very small dive into the fluent-setup of NLog-config.

[snakefoot]

I think it's nice! Only some naming things I guess

Created some unit-tests that increases code-coverage.

[snakefoot]

Btw. happy to see that NLog 4.7.0 seems to be swimming nicely along without any major issues. Not like NLog 4.6.0 where my refactoring of XmlLoggingConfiguration (To load NLog.config from appsettings.json) caused all kind of bad experiences.

But maybe I have just jinxed it, and the radio-silence comes from the corona dance :)

[snakefoot]

Should we include a CreateLogger() or GetCurrentClassLogger() / GetLogger() as extension-methods to ISetupBuilder ?

If you would like to remove the LogFactory-indirection ?

So this:

var logger = LogManager.Setup().LoadConfigurationFromAppSettings().LogFactory.GetCurrentClassLogger();

Becomes this:

var logger = LogManager.Setup().LoadConfigurationFromAppSettings().GetCurrentClassLogger();

[snakefoot]

One name thing, would it be easier? (So drop the NLog in the name)

I did that on purpose, because there is both "NLog.config" and "appsettings.json" and "app.config". All of them are files.

NLog gives special love and attention to NLog.config so yes it is the favorite file, but not the only one.

[304NotModified]

I did that on purpose, because there is both "NLog.config" and "appsettings.json" and "app.config". All of them are files.

Ah well I expected that "appsettings.json" and "app.config" would work (in the future) 👼

What about LoadConfig etc, and adding a optional "logFileType" parameter?

[304NotModified]

What about LoadConfig etc, and adding a optional "logFileType" parameter?

Ow that won't scale nice between other packages.

I stil prefer LoadConfig, but I think "appsettings.json" should be named other, e.g. LoadConfigFromAppsettingsJson

[snakefoot]

Ah well I expected that "appsettings.json" and "app.config" would work (in the future)

Never going to happen, since all of them have different dependencies, so they would require different assemblies (and extension-methods). Just like you see is happening in NLog.Extension.Logging and Nlog.Web.

P.S. It was my dream when I introduced LogManager.LoadConfiguration but now see it was a mistake.

[304NotModified]

nitpick: configFilePath?

[snakefoot]

Sounds like one is only giving the candidate-path to the NLog.config file. Not sure it is an improvement.

[304NotModified]

well configFile sounds a bit like the content of the configFile.

[304NotModified]

my dream

To what is this referring?

[snakefoot]

To what is this referring?

My dream that LogManager.LoadConfiguration should load all kind of files.

[304NotModified]

ow yes, that would be nice.

But you still prefer LoadNLogConfig over LoadConfig? I never saw the relation between "NLog" word and NLog.config (as dumb user is still would try LoadNLogConfig("appsettings.json"))

[snakefoot]

Yes to me LoadNLogConfig is better than LoadConfig. As it signals the file has to match the format of NLog.config. And the contents of the config is the NLog LoggingConfiguration, and not some other config.

[snakefoot]

I guess these two methods could have different name:

LogManager.Setup().LoadNLogConfig(nlogConfig);

LogManager.Setup().LoadNLogConfig(builder => )

Could also be called:

LogManager.Setup().LoadLoggingConfiguration(nlogConfig);

LogManager.Setup().LoadLoggingConfiguration(builder => )

[snakefoot]

Changed builder-method from LogFactory to ISetupNLogConfigBuilder then one can create config-extension-methods for the interface instead of for LogFactory.

[304NotModified]

I guess these two methods could have different name:

LogManager.Setup().LoadNLogConfig(nlogConfig);

LogManager.Setup().LoadNLogConfig(builder => )

Could also be called:

LogManager.Setup().LoadLoggingConfiguration(nlogConfig);

LogManager.Setup().LoadLoggingConfiguration(builder => )

That's IMO better. I don't think "NLog Should be in a method name, as we're already in a NLog context.

Why about LogManager.Setup().LoadConfiguration? It is consistent with LogManager.LoadConfiguration then.

[snakefoot]

Why about LogManager.Setup().LoadConfiguration?

Have updated the PR with the new names.

Some adjustment is needed for:

NLog/NLog.Extensions.Logging#412
NLog/NLog.Web#540

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
5 Code Smells

98.7% Coverage
0.0% Duplication

[304NotModified]

Cool! Thanks!

[snakefoot]

Created wiki-page: https://github.com/NLog/NLog/wiki/Fluent-Configuration-API