UseNLog allow fallback to only EnvironmentName for NLog config

[snakefoot]

Use LoadConfigurationFromFile instead of explicit creating XmlLoggingConfiguration for better NLog InternalLogger output.

[snakefoot]

@RWells-HUHS Please try testing with the pre-release nuget-package found here:

• https://ci.appveyor.com/project/nlog/nlog-web/builds/51027776/artifacts

Then I believe the NLog InternalLogger will give better output on NET9, so we figure out what causes NET9 to produce strange file-paths that leads to System.UriFormatException.

Just download the nuget-package NLog.Web.5.3.14.1175-PR1066.nupkg (from the link above), and place in a local folder. Then in Visual Studio setup nuget-package-source that points to the local-folder. Then you should be able to update your project to use this pre-release nuget-package (when having checked that you will allow pre-release-versions in the nuget-package-updater).

Then run your application after having made sure to enable NLog InternalLogger from code. at LogLevel.Debug.

[RWells-HUHS]

Side note: I had to rename the downloaded file from .zip to .nupkg to make it appear in Visual Studio.

[RWells-HUHS]

Congratulations! 5.3.14.1175-PR1066 doesn't exhibit the same error. :-)

The (failed) attempts to use the UNC are the same as under .12, but, as in the working .11, execution proceeds from there to use the mapped drive:

2024-11-20 16:09:15.9593 Debug Skip loading NLogLoggingConfiguration from empty config section: NLog
2024-11-20 16:09:15.9901 Info Loading NLog config from XML file: Z:\rwells\very\special\NLog.config

Fundamentally, whatever NLog is trying to do to get the UNC hostname out of the mapped drive isn't working, even in .11 and .14.1175-PR1066. But in .12 and .14 (I didn't actually test .13), some step between the statements that writes the two lines above throws that unhandled System.UriFormatException exception.

FWIW, the execution environment is in an unprivileged user session on Windows Server 2022. The drive mapping is memorized under my unprivileged user, to a restricted share on another Windows Server 2022 system.

[snakefoot]

@RWells-HUHS Thank you for the very fast confirmation. Will see if I can make the build-engines produce a new official release for nuget.

[sonarqubecloud]

Quality Gate failed

Failed conditions
79.2% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[snakefoot]

@RWells-HUHS Have now released NLog.Web.AspNetCore v5.3.15, so you should not be blocked.

But could be interesting if AppDomain.CurrentDomain.BaseDirectory is better alternative to System.AppContext.BaseDirectory on NET9 ? At least until NLog is no longer depending on XmlReader and path-validation by Uri.

[RWells-HUHS]

As mentioned in our related chat on SO, AppDomain.CurrentDomain.BaseDirectory contains same long UNC value as System.AppContext.BaseDirectory.

Separately, 5.3.15 is generally working for me, though I do get this build warning:

Package 'NLog.Web 5.3.15' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net9.0'. This package may not be fully compatible with your project.

I don't recall getting this with earlier 5.3.* versions.

[snakefoot]

You should remove the project-dependency on NLog.Web and only have dependency on NLog.Web.AspNetCore when using NET9

[RWells-HUHS]

Ah! Thanks. Didn't realize the two packages were mutually exclusive. (Migrating older .NET Framework codebase that used NLog.Web, so I had simply added NLog.Web.AspNetCore.)