Work with 'Mounted Network Drive' in .NET 9.0

[SMAH1]

I have Mounted Network Drive called 'U:' in my Windows 10 (version 22H2).
My web project is into U:\Project\UI2\CloudApi folder and use NLog 5.3.15 for loggin.
I used .NET 8.0 and everything was fine..
After update to .NET 9.0 and run project in my visual studio (2202), Throw exception The specified path is invalid. because my folder in Network Drive!

Exception is in System.Private.CoreLib and type is System.IO.IOException like:

The specified path is invalid. : '\\?\UNC\WinSrv\User-Data\AAAAAAAAAAAAAAAA\Project\UI2\CloudApi\src\bin\Debug\net9.0\.\Logs\nlog-all-2024-12-16.log'.

and detail of exception is:

Data	Count = 0	System.Collections.IDictionary {System.Collections.ListDictionaryInternal}
HResult	-2147024735	int
HasBeenThrown	true	bool
HelpLink	null	string
InnerException	null	System.Exception
Static members		
Message	"The specified path is invalid. : '\\\\?\\UNC\\WinSrv\\User-Data\\AAAAAAAAAAAAAAAA\\Project\\UI2\\CloudApi\\src\\bin\\Debug\\net9.0\\.\\Logs\\nlog-all-2024-12-16.log'."	string
SerializationStackTraceString	"   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)"	string
SerializationWatsonBuckets	null	object
Source	"System.Private.CoreLib"	string
StackTrace	"   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)"	string
TargetSite	{Microsoft.Win32.SafeHandles.SafeFileHandle CreateFile(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, System.IO.FileOptions)}	System.Reflection.MethodBase {System.Reflection.RuntimeMethodInfo}
_HResult	-2147024735	int
_data	Count = 0	System.Collections.IDictionary {System.Collections.ListDictionaryInternal}
_exceptionMethod	null	System.Reflection.MethodBase
_helpURL	null	string
_innerException	null	System.Exception
_ipForWatsonBuckets	0x00007fff4f272872	System.UIntPtr
_message	"The specified path is invalid. : '\\\\?\\UNC\\WinSrv\\User-Data\\AAAAAAAAAAAAAAAA\\Project\\UI2\\CloudApi\\src\\bin\\Debug\\net9.0\\.\\Logs\\nlog-all-2024-12-16.log'."	string
_remoteStackTraceString	null	string
_source	null	string
_stackTrace	{sbyte[48]}	object {sbyte[]}
_stackTraceString	null	string
_watsonBuckets	null	byte[]
_xcode	-532462766	int
_xptrs	0x0000000000000000	System.IntPtr
Static members		

[snakefoot]

It looks like NET9 has changed the output from AppDomain.CurrentDomain.BaseDirectory and System.AppContext.BaseDirectory when running from a network-drive. Instead of returning the network-drive-letter, then NET9 returns the Long UNC network-path behind the network-drive-letter. No idea why Microsoft have made this breaking change in NET9.

See also: https://stackoverflow.com/q/79208703/193178

Seems UNC-path must be "exact", so having "noise" like the dot (\\.\\) in net9.0\\.\\Logs\\nlog-all-2024-12-16.log will probably be seen as invalid. NLog uses Path.Combine for building absolute-paths so curious how you have configured the NLog FileTarget to generate this failing path. The easy solution would of course be that NET9 reverted its breaking change for BaseDirectory.

[snakefoot]

Looks similar to #109846

[Rob-Hague]

We have also encountered this, whereby .NET 9 apps which use NLog for logging have no output when run from a network drive, because the library fails to initialise. It does indeed look like #109846 is the cause

curious how you have configured the NLog FileTarget to generate this failing path

In our case we use a simple relative path e.g. fileName="logs/${shortdate}.log". The failure is happening before that: if we have W:\ConsoleApp.exe and W:\NLog.config then the failure results from a call to XmlReader.Create(inputUri: "\\?\UNC\server\NLog.config"). In .NET 8 this call is XmlReader.Create(inputUri: "W:\NLog.config"). Within System.Xml the inputUri gets passed to System.Uri constructor which throws:

System.UriFormatException: 'Invalid URI: The hostname could not be parsed.'

System.Private.Uri.dll!System.Uri.CreateThis(string uri, bool dontEscape, System.UriKind uriKind, System.UriCreationOptions creationOptions) Line 42
System.Private.Uri.dll!System.Uri.Uri(string uriString, System.UriKind uriKind) Line 412
System.Private.Xml.dll!System.Xml.XmlResolver.ResolveUri(System.Uri baseUri, string relativeUri) Line 45
System.Private.Xml.dll!System.Xml.XmlTextReaderImpl.XmlTextReaderImpl(string uriStr, System.Xml.XmlReaderSettings settings, System.Xml.XmlParserContext context, System.Xml.XmlResolver uriResolver) Line 588
System.Private.Xml.dll!System.Xml.XmlReader.Create(string inputUri) Line 1615
NLog.dll!NLog.Internal.Fakeables.AppEnvironmentWrapper.LoadXmlFile(string path) Line 116
NLog.dll!NLog.Config.LoggingConfigurationFileLoader.LoadXmlLoggingConfigurationFile(NLog.LogFactory logFactory, string configFile) Line 132
NLog.dll!NLog.Config.LoggingConfigurationFileLoader.TryLoadLoggingConfiguration(NLog.LogFactory logFactory, string configFile, out NLog.Config.LoggingConfiguration config) Line 97
NLog.dll!NLog.Config.LoggingConfigurationFileLoader.TryLoadFromFilePaths(NLog.LogFactory logFactory, string filename) Line 84
NLog.dll!NLog.Config.LoggingConfigurationFileLoader.Load(NLog.LogFactory logFactory, string filename) Line 62
NLog.dll!NLog.Config.LoggingConfigurationWatchableFileLoader.Load(NLog.LogFactory logFactory, string filename) Line 74
NLog.dll!NLog.LogFactory.Configuration.get() Line 272
NLog.dll!NLog.LogFactory.GetLoggerThreadSafe(string name, System.Type loggerType, System.Func<System.Type, NLog.Logger> loggerCreator) Line 998
NLog.dll!NLog.LogFactory.GetLogger(string name) Line 538
NLog.dll!NLog.LogManager.GetCurrentClassLogger() Line 205

[albertovelo]

Hello,
maybe I'm missing something, is there an alternative to AppDomain.CurrentDomain.BaseDirectory in order to get the path with the mapped drive letter like we had with .net 8? 🤨

[jeffhandley]

Assigned to @jozkee for triage.

[Rob-Hague]

This can be closed as a duplicate of #109846

[snakefoot]

@jozkee Notice that the bug-fix #110033 is planned to be back-ported to 9.0.x. See also milestone for: #111499 and #109846

[jeffhandley]

@jozkee Do you agree that this is a dupe of #109846?

[jozkee]

@jeffhandley yes.