System.Configuration.ConfigurationManager exposes settings and I was able to make these work for read, but they fail to save.
I see:
System.InvalidCastException
HResult=0x80004002
Message=Unable to cast object of type 'System.Configuration.ConfigurationUserLevel' to type 'System.Configuration.ConfigurationFileMap'.
Source=System.Configuration.ConfigurationManager
StackTrace:
at System.Configuration.Configuration..ctor(String locationSubPath, Type typeConfigHost, Object[] hostInitConfigurationParams)
at System.Configuration.Internal.InternalConfigConfigurationFactory.System.Configuration.Internal.IInternalConfigConfigurationFactory.Create(Type typeConfigHost, Object[] hostInitConfigurationParams)
at System.Configuration.ClientSettingsStore.WriteSettings(String sectionName, Boolean isRoaming, IDictionary newSettings)
at System.Configuration.LocalFileSettingsProvider.SetPropertyValues(SettingsContext context, SettingsPropertyValueCollection values)
at System.Configuration.SettingsBase.SaveCore()
at System.Configuration.SettingsBase.Save()
at settingsCore.Program.Main(String[] args) in c:\Users\ericstj\source\repos\settings\settingsCore\Program.cs:line 13
This appears to be a bug in ImplicitMachineConfigHost where it assumes the caller of IInternalConfigConfigurationFactory.Create will always specify a ConfigurationFileMap as the first parameter. This is not the case for ClientSettingsStore.OpenExeConfiguration which specifies a ConfigurationUserLevel.
I was able to workaround this by creating a private copy of ConfigurationManager that changed the casts in ImplicitMachineConfigHost to as ConfigurationFileMap but I'm not sure if that's the best fix: Can machine.config ever play a part in settings resolution? It doesn't seem likely but it may make sense to see what happens in desktop and see if falls back to anything in machine.config. If so, then we might want to see how to plumb ImplicitMachineConfigHost in this case.
Here's a repro project:
settingsCore.zip
I'm getting this on a Windows UWP app as well. I believe I'm using the latest .NET version.
Yes, the implementation is the same. /cc @JeremyKuhne
Moving to 2.2 per @JeremyKuhne's info and offline confirmation: https://github.com/dotnet/corefx/pull/28894#issuecomment-381366648
There are additional issues below the obvious issue. The linked PR can't make it past CI, but passes locally. Given the time I think this should be dealt with in 2.2 where we can give it time to bake (once we've figured out why it is tripping up).
Making sure this gets added to the WPF/WinForms support project. I encountered this when porting WPF/Winforms apps. Without a fix here the settings APIs are broken for saving customer settings (like app settings, UI state, etc).
@maryamariyan apparently @ericstj has a private change for this that seemed to work for him. Maybe you can take that and get it tested and submitted.
Actually @JeremyKuhne made a fix for this (+tests!) in 2.x but didn't merge because we couldn't get all the tests to pass across all platforms. I think Jeremy's fix is good we probably just need to resurrect it and make the tests pass / opt-out. https://github.com/dotnet/corefx/pull/28894
Just in case you need it, here was my smaller fix: https://devdiv.visualstudio.com/DevDiv/_git/DotNet-CoreFX-Trusted/commit/9fe6532ef52c3009850bf40688674b9744b788c4