I'm looking for a way to store application or machine level settings that can be written to at runtime using Application Settings. User settings allow read/write but application settings do not. I have been using user settings for saving settings like this at runtime but this has really proven to be impractical for the following reasons:
- All users of the machine need to share settings.
- In support calls (especially in crisis situations) it is difficult to explain to users/employees where to find and modify these settings manually (appdata is a hidden folder among other things).
- New versions of the app need to use previous settings (user settings seem to get blown away with new versions).
- It is common for our employees to copy the application to a new folder which also resets the user settings.
Our company machines are only used by one user anyway so user specific settings are not generally needed.
Otherwise I really like using application settings and would like to continue to use them if possible. It would be ideal if the settings could reside in the same folder as the EXE (like good ol' ini files once did).
NOTE: This is a WPF application and not an ASP.net web app so no web.config.
Well, I haven't yet wanted to change application settings at runtime (that's what I use user settings for), but what I have been able to do is write application settings at install time. I imagine that a similar approach might work at runtime. You could try it out since there don't seem to be any other propsed solutions ATM.
Hope that helps!
WPF applications are able to access the app.config file just like WinForms apps through the
method. The trick is to have the values you want to access in the AppSettings tag of your App.config file (also available in WPF applications).
The trick to all of this is to make sure to call the following methods when you're done modifying your properties:
I wrote a complete "how to" on this a little while back that explains it all here.
This is the method which allows you to change entries in the
<AppSettings>
:Note that I have found it is necessary to refresh the section
appSettings
after the update.The function removes a key before it adds it to avoid double entries. This works also if the key does not previously exist. If there is any error it returns false, on success true. The method to read settings is trivial and just listed for completeness:
Note that I've surrounded it by a try ... finally block to suppress errors. If any errors occur, then GetSetting simply returns null while SetSetting returns false. That makes handling easier, however if you require the exceptions you can still add
to throw the exception up to the caller. Or, for debugging you could add:
Which will show the exception in the Output window of Visual Studio if you have selected the "Debug" configuration, but will continue with the code.
Note (cross-reference to a similar topic):
The applicationSettings section is different, since it distinguishes between "User" and "Application" scope and it supports different datatypes, not just strings. If you want to know how you can handle applicationSettings, you can find it here (on stackoverflow):
How to access applicationSettings
If you are uncertain whether you should use
AppSettings
orapplicationSettings
, then read this before you decide it.If you encounter the warning
'ConfigurationSettings.AppSettings' is obsolete
, then this hint can help you.