NLog 5.0 makes it possible to resolve interfaces using dependency injection during initialization. This allows you to load targets using NLog config file, before dependency injection provider is available.

The custom NLog target can then overrideInitializeTarget to resolve the necessary dependencies:

protectedoverridevoidInitializeTarget(){varwantedDependency=base.ResolveService<IWantedDependency>();base.InitializeTarget();}

If the custom NLog target requests a dependency, that is unavailable, then NLog will perform re-initialization of the NLog when the dependency becomes available. Service interfaces can registered like this:

NLog.LogManager.Setup().SetupExtensions(ext=>RegisterSingletonService<IWantedDependency>(wantedInstance));

It is also possible to connect with an externalIServiceProvider for resolving dependencies:

NLog.LogManager.Setup().SetupExtensions(ext=>RegisterServiceProvider(serviceProvider));

It is recommended to setup dependency-injection early before loading the NLog LoggingConfiguration, or else they might not take effect.

NLog v5.2 introduces the ability to register extensions together with custom factory-method:

NLog.LogManager.Setup().SetupExtensions(ext=>RegisterTarget<MyTarget>(()=>newMyTarget(wantedDependency));

⚠️ NLog v5.2 has markedConfigurationItemFactory.CreateInstance as obsolete, as it doesn't work well with Ahead-of-Time (AOT) application trimming in .NET

NLog will by default use the default constructor for creating new objects. It is possible to override the creation by usingConfigurationItemFactory.CreateInstance. Example:

usingNLog.Config;vardefaultConstructor=ConfigurationItemFactory.Default.CreateInstance;ConfigurationItemFactory.Default.CreateInstance.CreateInstance= type=>{if(type==typeof(MyCustomTarget))returnnewMyCustomTarget(myCustomParameter);returndefaultConstructor(type);};

NLog will only be able to create objects of known types. To support custom objects one must also register the config-item-type before it will be recognized. See alsoRegister your custom component

The combination of dynamic logging configuration and dependency injection can give a catch22. You want to have logging up and running early, but this will fail if dependent on custom objects that requires a dependency injection provider is fully loaded.

The "ugly" work-around to this catch22 is to have two constructors for your custom-objects:

• Default Constructor that initializes an object in disabled state (Ignored by dependency injection provider).
• Specialized Constructor that initializes an object in working state.

Alternative override theCreateInstance-method as first thing (Before creating first Logger-object or loading NLog config). Where it calls the specialized constructor with parameters that signals that it should be in disabled state.

Then one can "just" perform a reload of the NLog config, after the dependency injection provider has been fully loaded and performed final override ofCreateInstance. This will make NLog recreate all configuration items once again, and now with a working dependency injection provider that calls the specialized constructor with correct parameters.

usingNLog;LogManager.Configuration=LogManager.Configuration.Reload();

See alsoReinitialize NLog configuration