Description

When trying to call the Upgrade function on an implementation of ApplicationSettingsBase, with the executable located on a network drive, the call will fail with an System.ArgumentNullException originating from System.Configuration.LocalFileSettingsProvider.GetPreviousConfigFileName.

Reproduction Steps

1. Create app that calls settings.Upgrade() on any class extending ApplicationSettingsBase
2. Deploy application on network drive
3. Said call will yield an exception.

MWE available at https://github.com/jnoordsij/dotnet-settings-upgrade-bug-mwe/:

• the dist directory contains the output of dotnet publish -o dist/
• if dist/dotnet-settings-mwe.exe is executed on a local drive, application runs fine
• if dist/dotnet-settings-mwe.exe is executed on a network drive, the exception-wrapping message box will appear

Expected behavior

No exception to appear on call to .Upgrade()

Actual behavior

Exception is thrown with following trace:

System.ArgumentNullException: Value cannot be null. (Parameter 'path')
   at System.ArgumentNullException.Throw(String paramName)
   at System.ArgumentNullException.ThrowIfNull(Object argument, String paramName)
   at System.ArgumentException.ThrowNullOrEmptyException(String argument, String paramName)
   at System.IO.Directory.GetParent(String path)
   at System.Configuration.LocalFileSettingsProvider.GetPreviousConfigFileName(Boolean isRoaming)
   at System.Configuration.LocalFileSettingsProvider.Upgrade(SettingsContext context, SettingsPropertyCollection properties, Boolean isRoaming)
   at System.Configuration.ApplicationSettingsBase.Upgrade()
   ...

Regression?

This seems to occur on .NET 9 only.

Known Workarounds

• Use .NET 8 (or lower) for building
• Deploy application on non-network drive

Configuration

Observed on:

• .NET runtime 9.0.0
• Windows 11 x64

Probably not specific to the latter, but definitely to the first.

Other information

This might be related to or caused by #109846.

I've first observed this happen on the Upgrade call, but other calls like Save are effected in a similar manner, most likely all due to the same underlying cause.

I've also observed that the value of ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath outputs an empty string when application is on a network drive, contrary to the (correct) local path outputted when application is on a local drive.