I need to have a common application settings file and i need it to be editable by the application at runtime.
I don’t want to use the build in settings operation by putting “User” in settings scope because it gets saved in users local directory.
On the other hand i cant use the .config with “Application” as i cannot save into this file from within the application.
One might say “Create your own save settings XML file its easy”..Yes probably it is but i wonder what is the solution for a common writable config file with MS build in classes?
To have data, whatever the format, updateable by all users then all users need to be able to save to whatever container holds that data.
This applies whatever the format, from text file to RDBMS.
The problem with a file that you manage (eg.
.config(XML) file) is twofold:The
ConfigurationManagerand associated classes will write to a.exe.configfile with applicable declaration of the configuration elements and properties, but the underlying file has to be writeable. You’ll need to:Set an ACL in an installer so all (applicable) users have write access. This means outside the application they can write as well, this is unavoidable as there is no ability to set access control based on application.
Install outside
Program Files. UAC virtualises writes toProgram Files(so applications assuming all users can write anywhere don’t break), but this also means it cannot be used for shared modifiable data.Concurrency is another problem. What is two users both modify the shared data together? One user will overwrite the others changes unless you implement some locking and reloading on changed.
Consider using a multi-user database for the data instead. They are designed for this kind of thing, Config files are not.
Update (based on comment):
To have a (non-admin) user update a
.exe.configin Program Files will still hit UAC virtualisation (ie. any writes will be directed to a per-user location, and not-visible to anyone else).Easier to use the
ConfigurationManager.OpenExeConfiguration(string)method to load a.configfrom some shared location (eg. inC:\ProgramData1) which has an appropriate ACL. The returnedConfigurationobject has all the capabilities of the implicit load from.exe.configfor<appSettings>as well as custom sections, plus access toSaveandSaveAs.1 Of course using correct methods to get actual local path, not hardcoding.