In the February issue, I delved into the new configuration API included in the newly named .NET Core 1.0 platform (see bit.ly/1OoqmkJ). (I assume most readers have heard about the recently renamed .NET Core 1.0, which was formerly referred to as .NET Core 5 and part of the ASP.NET 5 platform [see bit.ly/1Ooq7WI].) In that article I used unit testing in order to explore the Microsoft.Extensions.Configuration API. In this article I take a similar approach, except with Microsoft.Extensions.Logging. The key difference in my approach is that I’m testing it from a .NET 4.6 CSPROJ file rather than an ASP.NET Core project. This emphasizes the fact that .NET Core is available for you to consider using immediately—even if you haven’t migrated to ASP.NET Core projects.
Logging? Why on earth do we need a new logging framework? We already have NLog, Log4Net, Loggr, Serilog and the built-in Microsoft.Diagnostics.Trace/Debug/TraceSource, just to name a few. As it turns out, the fact that there are so many logging frameworks is actually one of the driving factors that make Microsoft.Extensions.Logging relevant. As a developer faced with the myriad of choices, you’re likely to select one knowing you might have to switch to another one later. Therefore, you’re probably tempted to write your own logging API wrapper that invokes whichever particular logging framework you or your company chooses this week. Similarly, you might use one particular logging framework in your application, only to find that one of the libraries you’re leveraging is using another, causing you to have to write a listener that takes the messages from one to the other.
Read the rest at https://msdn.microsoft.com/en-us/magazine/mt694089