How can I read/write app.config settings at runtime without using user settings?
Asked Answered
D

3

16

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.

Denadenae answered 3/9, 2010 at 19:1 Comment(2)
Storing writable settings in the same directory as the exe is a bad idea - on Vista/Win7, this requires admin writes and will trigger UAC and cause your app to be run elevated. Better to store app settings elsewhere.Vigesimal
@Vigesimal That does not seem right to me. I written many programs that write to xml files in the same directory as the EXE without triggering UAC.Denadenae
B
9

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.

    exePath = Path.Combine( exePath, "MyApp.exe" );
    Configuration config = ConfigurationManager.OpenExeConfiguration( exePath );
    var setting = config.AppSettings.Settings[SettingKey];
    if (setting != null)
    {
        setting.Value = newValue;
    }
    else
    {
        config.AppSettings.Settings.Add( SettingKey, newValue);
    }

    config.Save();

Hope that helps!

Bonitabonito answered 9/9, 2010 at 17:22 Comment(0)
M
7

This is a method which allows you to change entries in the <AppSettings>:

    internal static bool SetSetting(string Key, string Value)
    {
        bool result = false;
        try
        {
            System.Configuration.Configuration config =
              ConfigurationManager.OpenExeConfiguration(
                                   ConfigurationUserLevel.None);

            config.AppSettings.Settings.Remove(Key); 
            var kvElem= new KeyValueConfigurationElement(Key, Value);
            config.AppSettings.Settings.Add(kvElem);

            // Save the configuration file.
            config.Save(ConfigurationSaveMode.Modified);

            // Force a reload of a changed section.
            ConfigurationManager.RefreshSection("appSettings");                

            result = true;
        }
        finally
        { }
        return result;
    } // function

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:

    internal static string GetSetting(string Key)
    {
        string result = null;
        try
        {
            result = ConfigurationManager.AppSettings[Key];
        }
        finally
        { }
        return result;
    } // function

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

        catch (Exception) { throw; }

to throw the exception up to the caller. Or, for debugging you could add:

        #if DEBUG
        catch (Exception ex) { 
                System.Diagnostics.Debug.WriteLine(ex.ToString()); 
        }
        #endif

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 or applicationSettings, then read this before you decide it.

  • If you encounter the warning 'ConfigurationSettings.AppSettings' is obsolete, then this hint can help you.

  • If you're using the .NET Core framework, check out this link: AppSettings in .NET Core


More information:

Mane answered 7/8, 2012 at 7:27 Comment(0)
O
3

WPF applications are able to access the app.config file just like WinForms apps through the

ConfigurationManager.OpenExeConfiguration()

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:

MyConfig.Save(ConfigurationSaveMode.Modified)
ConfigurationManager.RefreshSection("appSettings")

I wrote a complete "how to" on this a little while back that explains it all here.

Oligocene answered 9/9, 2010 at 17:30 Comment(2)
This doesn't work if the user doesn't have the correct UAC permissions.Solipsism
@Solipsism Good point. I guess the other assumption is that the application is installed in a location where one can modify this file.Oligocene

© 2022 - 2024 — McMap. All rights reserved.