Microsoft.Extensions.Logging.Log4Net.AspNetCore 10.0.0

Microsoft.Extensions.Logging.Log4Net.AspNetCore

Allows to configure Log4net as Microsoft Extensions Logging handler on any ASP.NET Core application.

Thanks to @anuraj for this original blog post.

👁 Release Build
👁 NuGet

GitHub Actions deployment

The documented release workflow runs in GitHub Actions. It builds, tests, and packs the NuGet package on main and on manual dispatch.

If you want assembly signing to remain enabled in GitHub, add these repository secrets:

• SIGNING_SNK_BASE64 for Microsoft.Extensions.Logging.Log4Net.AspNetCoreKey.snk
• SIGNING_PFX_BASE64 for the companion private certificate file, if you want to keep that asset available privately
• SIGNING_PUBLIC_KEY_BASE64 for the public key file, if you want to keep that asset available privately

The workflow restores any configured signing assets into the runner at runtime; none of the signing files need to be committed to the repository.

Example of use

• Install the package or reference the project into your asp.net core application.

• Add the AddLog4Net() call into your Configure method of the Startup class.

using Microsoft.Extensions.Logging;

public class Startup
{
 //...

 public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
 {
 //...

 loggerFactory.AddLog4Net(); // << Add this line
 app.UseMvc();

 //...
 }
}

• For dotnet 6.0 and later add builder.Logging.AddLog4Net(); call in your Program.cs file.

• Add a log4net.config file with the content:

<?xml version="1.0" encoding="utf-8" ?>
<log4net>
 <appender name="DebugAppender" type="log4net.Appender.DebugAppender" >
 <layout type="log4net.Layout.PatternLayout">
 <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
 </layout>
 </appender>
 <root>
 <level value="ALL"/>
 <appender-ref ref="DebugAppender" />
 </root>
</log4net>

You can found more configuration examples on configuration documentation.

FAQ

Using BeginScope

Associated issues #45

From version 2.2.7, this nuget allow to use the BeginScope method from Log4NetLogger.

var dictionary = new Dictionary<string, string>() { { "test", "SCOPED_VALUE" } };
using (var scope = logger.BeginScope(dictionary))
{
 logger.LogCritical(message);
}

The BeginScope method allow any object, but only some of types are handled in an special way. Those types are:

• string
• IEnumerable<KeyValuePair<string, string>>
• IEnumerable<KeyValuePair<string, object>>
• ValueTuple<string, T> where T is string, any numeric type or object

By default, any other type will be managed as a conventional object.

How it works

When you use any of the IEnumerable<KeyValuePair<,>> allowed types, the collection will be processed and every item from this collection should be introduced to the LogicalThreadContext managed by the log4net library using the Key as the property name and the Value as the value to replace the placeholder on the Pattern Layout defined.

This example shows how the log4net.config pattern layout could include a %property{} placeholder that will be matched within the corresponding scoped value from the collection argument.

<layout type="log4net.Layout.PatternLayout">
 
 <conversionPattern value="%date [%thread] %-5level %logger %ndc - scope=%property{scope} - %property{custom_name} - %message%newline" />
</layout>

When you use the BeginScope method passing a collection that contains a KeyValuePair within the key custom_name, the logged message will contain the SCOPED_VALUE text on it.

var dictionary = new Dictionary<string, string>() { { "custom_name", "SCOPED_VALUE" } };
using (var scope = logger.BeginScope(dictionary))
{
 logger.LogCritical(message); // SCOPED_VALUE will replace the %property{custom_name} placeholder
}

At the other hand, if the argument is not from the given IEnumerable<KeyValuePair<,>>, the value will be logged on the default scope property.

using (var scope = logger.BeginScope("SCOPED_VALUE"))
{
 logger.LogCritical(message); // SCOPED_VALUE will replace the %property{scope} placeholder
}

using (var scope = logger.BeginScope(Guid.NewGuid()))
{
 logger.LogCritical(message); // Guid value will replace the %property{scope} placeholder
}

And, when you use two chained BeginScope calls...

using (var scope = logger.BeginScope("SCOPED_VALUE"))
{
 using (var scope = logger.BeginScope(Guid.NewGuid()))
 {
 logger.LogCritical(message); // SCOPED_VALUE and Guid value (both) will replace the %property{scope} placeholder
 }
}

For additional information about how the LogicalThreadContext works, please visit the official documentation

.NET Core 2.0 - Logging debug level messages

Associated issues #34 & #41

In order to be able to register Debug level messages in any of your configured log4net appenders, you should change the ASP .NET Core 2 configuration when you build your IWebHost instance as follows.

public static IWebHost BuildWebHost(string[] args) =>
 WebHost.CreateDefaultBuilder(args)
 .UseStartup<Startup>()
 .ConfigureLogging((hostingContext, logging) =>
 {
 // The ILoggingBuilder minimum level determines the
 // the lowest possible level for logging. The log4net
 // level then sets the level that we actually log at.
 logging.AddLog4Net();
 logging.SetMinimumLevel(LogLevel.Debug);
 })
 .Build();

Logging lower than the Information Level

Associated issues #85

Also note that when trying to allow for levels messages below the Information level for a development build you must make allowances for it in the appsettings.Development.json as specified in the documentation and illustrated below:

{
 "Logging": {
 "LogLevel": {
 "Default": "Debug",
	 "...":"..."
 }
 }
}

Modifying logging behaviour

In many cases you can modfiy the logging behaviour of the provider to fit your own needs. See modifying logging behaviour for more information.

Special thanks

Thank you very much to all contributors & users by its collaboration, and specially to:

• @twenzel by his great job on adapting the library to the new logging recomendations for .NET Core 2.
• @sBoff by the fix of the mutiple calls to XmlConfigurator.Configure issue.
• @kastwey by the feature to allow to replace values of log4net.config using the Microsoft.Extensions.Configuration.
• @willwolfram18 by bugfixing Log4NetScopeFactory usage when provided in Log4NetProviderOptions.
• @lscorcia by the fix of incorrect call stack when logging.
• @JustusGreiberORGADATA by the inclusion of a configurable logging event factory, and IExternalScope provider implementation.
• @Radim Holek for enabling ValueTuple mapping in scopes.