ApplicationSettingsBase.Upgrade() throws ArgumentNullException when run under fresh new user in macOS

[snechaev]

Description

In my console application I use the old-style Properties.Settings concept. For now this implemented with help of the System.Configuration.ConfigurationManager nuget package.

When I call Properties.Settings.Default.Upgrade(); on the newly created macOS user, I get the ArgumentNullException with the following stacktrace

Unhandled exception. 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.LocalFileSettingsProvider.Upgrade(SettingsContext context, SettingsPropertyCollection properties)
   at System.Configuration.ApplicationSettingsBase.Upgrade()
   at Program.<Main>$(String[] args) in /Users/user/testUpgrade/Program.cs:line 15
zsh: abort       

Reproduction Steps

• Download the test project test.zip
• Publish with dotnet publish
• (!) Important: make sure that the following folders do NOT exist (they are really do not exist for the fresh newly created user)
  • ~/.config/
  • ~/.local/
• Run the published application directly ((!) do not use dotnet run, as it internally create settings folder before actually running the app)
• Observe exception as described above (or, if the mentioned folder still exists, then you will see corresponding note and no crash)

Expected behavior

Application finished without exceptions.

Actual behavior

Unhandled ArgumentNullException inside LocalFileSettingsProvider

Unhandled exception. 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.LocalFileSettingsProvider.Upgrade(SettingsContext context, SettingsPropertyCollection properties)
   at System.Configuration.ApplicationSettingsBase.Upgrade()
   at Program.<Main>$(String[] args) in /Users/user/testUpgrade/Program.cs:line 15

Regression?

The problem can be reproduced in net6/7.

Known Workarounds

No response

Configuration

• net versions I have tried: 6.0.408, 7.0.310, 8.0.101`
• System.Configuration.ConfigurationManager package versions: 6.0.1 and 8.0.0
• macOS: 13.6.4 Ventura (x86) and 14.3.1 Sonoma (ARM64/Apple M2)
• Important: tested on newly created macos used, so no one has created settings folders yet.

Other information

When the ~/.local/ and ~/.config folder are missing, the system can't build a path to the settings file, so
ConfigurationManager.OpenExeConfiguration(level).FilePath gives null (or empty string) for the level = ConfigurationUserLevel.PerUserRoamingAndLocal and level = ConfigurationUserLevel. PerUserRoaming.

When executing Upgrade() the ConfigurationManagerInternalFactory.Instance.ExeRoamingConfigDirectory and ConfigurationManagerInternalFactory.Instance.ExeLocalConfigDirectory are null here

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/LocalFileSettingsProvider.cs

Lines 288 to 290 in 46870a0

	string userConfigPath = isRoaming
	? ConfigurationManagerInternalFactory.Instance.ExeRoamingConfigDirectory
	: ConfigurationManagerInternalFactory.Instance.ExeLocalConfigDirectory;

And then we got exception in Directory.GetParent(null) here

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/LocalFileSettingsProvider.cs

Line 302 in 46870a0

DirectoryInfo parentDirectory = Directory.GetParent(userConfigPath);

Tagging subscribers to this area: @dotnet/area-system-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

In my console application I use the old-style Properties.Settings concept. For now this implemented with help of the System.Configuration.ConfigurationManager nuget package.

When I call Properties.Settings.Default.Upgrade(); on the newly created macOS user, I get the ArgumentNullException with the following stacktrace

Unhandled exception. 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.LocalFileSettingsProvider.Upgrade(SettingsContext context, SettingsPropertyCollection properties)
   at System.Configuration.ApplicationSettingsBase.Upgrade()
   at Program.<Main>$(String[] args) in /Users/user/testUpgrade/Program.cs:line 15
zsh: abort       

Reproduction Steps

• Download the test project test.zip
• Publish with dotnet publish
• (!) Important: make sure that the following folders do NOT exist (they are really do not exist for the fresh newly created user)
  • ~/.config/
  • ~/.local/
• Run the published application directly ((!) do not use dotnet run, as it internally create settings folder before actually running the app)
• Observe exception as described above (or, if the mentioned folder still exists, then you will see corresponding note and no crash)

Expected behavior

Application finished without exceptions.

Actual behavior

Unhandled ArgumentNullException inside LocalFileSettingsProvider

Unhandled exception. 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.LocalFileSettingsProvider.Upgrade(SettingsContext context, SettingsPropertyCollection properties)
   at System.Configuration.ApplicationSettingsBase.Upgrade()
   at Program.<Main>$(String[] args) in /Users/user/testUpgrade/Program.cs:line 15

Regression?

The problem can be reproduced in net6/7.

Known Workarounds

No response

Configuration

• net versions I have tried: 6.0.408, 7.0.310, 8.0.101`
• System.Configuration.ConfigurationManager package versions: 6.0.1 and 8.0.0
• macOS: 13.6.4 Ventura (x86) and 14.3.1 Sonoma (ARM64/Apple M2)
• Important: tested on newly created macos used, so no one has created settings folders yet.

Other information

When the ~/.local/ and ~/.config folder are missing, the system can't build a path to the settings file, so
ConfigurationManager.OpenExeConfiguration(level).FilePath gives null (or empty string) for the level = ConfigurationUserLevel.PerUserRoamingAndLocal and level = ConfigurationUserLevel. PerUserRoaming.

When executing Upgrade() the ConfigurationManagerInternalFactory.Instance.ExeRoamingConfigDirectory and ConfigurationManagerInternalFactory.Instance.ExeLocalConfigDirectory are null here

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/LocalFileSettingsProvider.cs

Lines 288 to 290 in 46870a0

	string userConfigPath = isRoaming
	? ConfigurationManagerInternalFactory.Instance.ExeRoamingConfigDirectory
	: ConfigurationManagerInternalFactory.Instance.ExeLocalConfigDirectory;

And then we got exception in Directory.GetParent(null) here

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/LocalFileSettingsProvider.cs

Line 302 in 46870a0

DirectoryInfo parentDirectory = Directory.GetParent(userConfigPath);

Author:	snechaev
Assignees:	-
Labels:	area-System.Configuration, untriaged
Milestone:	-

[buyaa-n]

Expected behavior

Application finished without exceptions.

Other information

When the ~/.local/ and ~/.config folder are missing, the system can't build a path to the settings file, so
ConfigurationManager.OpenExeConfiguration(level).FilePath gives null (or empty string) for the level = ConfigurationUserLevel.PerUserRoamingAndLocal and level = ConfigurationUserLevel. PerUserRoaming.

I am not sure if this is expected to work, at least I don't think this is configuration issue. If the settings file were expected to be generated on Mac that is most likely issue in VS Mac issue, then it should be reported there.

@ericstj @steveharter what you think?

[snechaev]

@buyaa-n, just a note: VS Mac is completely unrelated here, it's not even used anywhere in the scenario. The initial code was written on Windows, compiled with dotnet cli (on macOS) and launched from the Finder. The problem is not with the dev-environment, it's with application work after deployment to the client machine, where neither dotnet nor VS was installed.

[ericstj]

Probably something unrelated during the build process creates .local and .config directories when you do dotnet run.

It sounds like this issue has a workaround - your application can explicitly create those directories.

I do think this is a bug though - we shouldn't be throwing an ArgumentNullException from framework code when the user has no control of the argument. This code path tries to deal with a non-existent folder, but it doesn't deal with null.

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/LocalFileSettingsProvider.cs

Lines 302 to 304 in 9d906a2

	DirectoryInfo parentDirectory = Directory.GetParent(userConfigPath);
	if (parentDirectory.Exists)

Seems to me like something went wrong when constructing the paths to leave them with a null value. I think this location is the place they should be set, and looking at

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs

Lines 162 to 165 in 7608b3a

	string localFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
	if (Path.IsPathRooted(localFolderPath))
	{
	LocalConfigDirectory = CombineIfValid(localFolderPath, dirSuffix);

It uses GetFolderPath to obtain the root, which gets called with SpecialFolderOption.None

runtime/src/libraries/System.Private.CoreLib/src/System/Environment.cs

Line 124 in e2acec9

public static string GetFolderPath(SpecialFolder folder) => GetFolderPath(folder, SpecialFolderOption.None);

Which means, that at this point, it's going to try to try to access and check for read.

runtime/src/libraries/System.Private.CoreLib/src/System/Environment.GetFolderPathCore.Unix.cs

Lines 28 to 46 in e2acec9

	if (path.Length == 0 ||
	option == SpecialFolderOption.DoNotVerify ||
	Interop.Sys.Access(path, Interop.Sys.AccessMode.R_OK) == 0)
	{
	return path;
	}
	// Failed verification. If None, then we're supposed to return an empty string.
	// If Create, we're supposed to create it and then return the path.
	if (option == SpecialFolderOption.None)
	{
	return string.Empty;
	}
	Debug.Assert(option == SpecialFolderOption.Create);
	Directory.CreateDirectory(path);
	return path;

This will fail because the folder doesn't exist. That is intentional per the docs:

None	0	The path to the folder is verified. If the folder exists, the path is returned. If the folder does not exist, an empty string is returned. This is the default behavior.

So I think we either need to change our call to GetFolderPath to not validate -- could be risky as it might change legit error paths, or cause side effects -- or just examine the places that might access these paths and make sure they can handle a null value.

[snechaev]

It sounds like this issue has a workaround - your application can explicitly create those directories.

Yes, my current workaround is as follows.

//should be called before any interactions with the settings
//(should work before the static members initialisers inside ConfigurationManager-related stuff.
private static void FixMacSettigns()
{
    var homePath = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
    var foldersToCheck = new[] { ".config/", ".local/share/" }.Select(x => Path.Combine(homePath, x));
    foreach (var path in foldersToCheck)
    {
        Directory.CreateDirectory(path);
    }
}

The drawbacks are

• you can only hardcode paths. If you will try to get the path from the ConfigurationManger, then (in case if paths do not not exist on disk)
  • you will get null
  • the static members of the ConfigurationManger will be initialised and even though the workaround will create the missing folders, the ConfigurationManger will still fail because the static members are already in the state that reflects the fact that folders are missing.
• I haven't checked the internal logic of how the path of the settings file is built, so if such paths can be different depending on the environment (OS version, permissions, and so on), then such a fix with hardcoded paths will fail.