NLog
Update AspNetCore and Hosting Dependencies/Features to Match MEH
Bug(?)/Improvement(?)
NLog version: 4.6.8 NLog.Extensions.Logging version: 1.6.1 NLog.Web.AspNetCore version: 4.9.0
Platform: .NET Framework 4.8, .NET Core 3.1, .NET Standard 2.0
Currently there are features that could be universally supported for all applications referencing the Microsoft.Extensions.Hosting generic application host but that are only currently supported in ASP.NET Core (e.g. ${aspnet-environment}). Since ASP.NET Hosting now uses Microsoft.Extensions.Hosting and desktop applications that are likely to use Microsoft.Extensions.Logging will often do so through Microsoft.Extensions.Hosting going forward it seems like the feature support (and dependency hierarchy) should be organized in the same order as the Microsoft types (i.e. since Microsoft's Dependencies go ASP.NET -> Microsoft.Extensions.Hosting -> Microsoft.Extensions.Logging it would be ideal for NLog dependencies to mirror this, e.g. NLog.Web.AspNetCore -> NLog.Extensions.Hosting -> NLog.Extensions.Logging)
One reason this comes up for us is because we use Microsoft.Extensions.Hosting for a single product that contains both .NET 4.8 and .NET Core 3.1 applications. For re-use and establishing base patterns we have various hosting libraries with extension methods to set the hosts up the way we like and since our general NLog extensions (we have custom formatters, conditions, etc.) and common NLog.config file are universal they are defined in a library that also exposes the extension methods designed to be used with Microsoft.Extensions.Hosting. Now that we're adding an ASP.NET Core hosting library, it references NLog.Web.AspNetCore as well as our NLog package (and therefore references NLog.Extensions.Hosting).
We would really like to use the environment name in our universal config file but they are currently only features of the ASP.NET Core. Additionally we would like our dependency hierarchies for the packages we're generating and consuming to match up to reduce risk of divergence in the future (this hasn't caused an critical issues yet so far as I can tell, but it seems like it would make sense).
NLog.Web.AspNetCore -> NLog.Extensions.Hosting -> NLog.Extensions.Logging)
I think this is a good idea!
But I don't fully understand why you can't use NLog.Web.AspNetCore+NLog.Extensions.Hosting now?
Is that because NLog.Extensions.Hosting is targeting less platforms (no netstandard 1.x, no net framework)?
We are using both, it's mostly just that there are features that were originally implemented in the ASP.NET package which can now be supported in the generic host package. We'd like to use those in the config file we share with both packages. The rest is more of a conceptual arrangement of dependencies since our AspNetCore hosting package references our MEH package which references our logging package (the same as the MS dependency chain) but the NLog refs we have don't follow the same hierarchy.
It would also be ideal to expose IHostEnvironment.ApplicationName alongside IHostEnvironment.Environment since we intend to use both; I didn't realize the application name wasn't already supported in the ASP.NET Core side until I tried documenting this request alongside our changes.
@TheXenocide You are very welcome to create a pull-request with your ideas.
it would be ideal for NLog dependencies to mirror this, e.g.
NLog.Web.AspNetCore -> NLog.Extensions.Hosting -> NLog.Extensions.Logging)
We have already, NLog.Extensions.Hosting -> NLog.Extensions.Logging`. So we only need NLog.Web.AspNetCore -> NLog.Extensions.Hosting.
So moving this to the NLog.Web repo
Indirectly the dependencies won't change as:
- NLog.Extensions.Hosting depends on Microsoft.Extensions.Hosting.Abstractions
- NLog.Web.AspNetCore depends on Microsoft.Extensions.Hosting.Abstractions and
- Microsoft.Extensions.Hosting.Abstractions also depends on Microsoft.Extensions.Hosting.Abstractions
ow the platform support is different
- https://www.nuget.org/packages/NLog.Extensions.logging
- https://www.nuget.org/packages/NLog.Extensions.Hosting
- doesn't support .NET Standard 1.3/1.5 and .NET 4.51/4.6
--> https://github.com/NLog/NLog.Extensions.Logging/issues/526
With the drop of ASP.NET Core 1 and https://github.com/NLog/NLog.Extensions.Logging/issues/528, we could do this :)
Unfortunate this isn't an option regarding .NET 4.6.1. See https://github.com/NLog/NLog.Extensions.Logging/pull/527
The issue is then we could not support ASP.NET Core 2 with .NET 4.6.1. And for now that is still supported.