I am looking into packaging an application that is .NET Framework 4.6 using WinForms and uses System.Configuration to read and write settings. The application contains a XXX.exe.Config file in the application directory with the initial settings. When using System.Configuration, the application does not use the filepath when reading or writing the configuration, this is handled by the api utility internally.
When the application starts up, it is able to read the settings correctly. When settings are changed, the application calls System.Configuration.SettingsBase.Save to save off the changes and this consistently fails with an exception with error 0x03 (Path not found), without or without the PSF.
When the application opens the file to read, the internal parts of System.Configuration call CreateFile and this is interceptable by the PSF. The PSF FRF will copy the file to the WritablePackageRoot area and allowing it to read from there. This is fine for the read operation and the settings from the package config file are seen.
When the app calls Save() for a modified configuration, the call trace shows that the utility internally uses System.Security.AccessControl.FileSecurity to change the security access to the file and this fails. This may be because the call uses the original path, but even then, the error should be a permissions error (the normal path file exists but is immutable) and not Path Not Found. But in any case, no call to CreateFile/CreateFileEx/CreateFile2 is ever made in the process monitor trace.
Is there a way to solve this problem as it seems to be a reasonable thing for an app to do?
The application in question is mRemoteNG which is freely downloadable, however it represents a class of applications that use this method of dealing with settings. (PS: The app works great under App-V).
~Tim
