ConfigurationManager doesn't save settings

Question

Here is the code I'm using:

private void SaveConfiguration()
{
    if (txtUsername.Text != "" && txtPassword.Text != "")
    {
        ConfigurationManager.AppSettings["Username"] = txtUsername.Text;
        ConfigurationManager.AppSettings["Password"] = txtPassword.Text;

        MessageBox.Show("Su configuracion guardo exitosamente.", "Exito!");
        this.Close();
    }
    else
    {
        MessageBox.Show("Por favor lleno los campos.", "Error.");
    }
}

Now, the settings are persisted but when I close the application and press F5 to run it again, the values are reverted to what is typed into the app.config file. Any suggestions?

Alain

you should probably think about using string.IsNullOrEmpty(...) instead of comparing to "" :) – Longish

Answer 1

I think you should call the Save method

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

EDIT

To be able to save you have to use a configuration object returned by the OpenExeConfiguration Method

//Create the object
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

//make changes
config.AppSettings.Settings["Username"].Value = txtUsername.Text;
config.AppSettings.Settings["Password"].Value = txtPassword.Text;

//save to apply changes
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("appSettings");

More references here ConfigurationManager Class

Dori

There is no .Save() method. – Alain

In order to get this working I had to use this config.AppSettings.Settings["Username"].Value = txtUsername.Text; config.AppSettings.Settings["Password"].Value = txtPassword.Text; – Emmen

Your last line of code is incorrect. It should be ConfigurationManager.RefreshSection(). Configuration class does not have a RefreshSection method. – Snowmobile

I do not have a Visual studio now to check the code and it's a while i'm not working with this class so i could be wrong. I thought i copy/paste them from a working source but i could have made some mistake when i posted the edit. Are you sure you tested it on the correct framework version? If you are sure i can edit it – Dori

Answer 2

When you run your application with F5,

• your code is compiled,
• the executable is copied to the bin or bin\Debug subdirectory of your source code directory,
• your app.config is copied as yourexecutable.exe.config into that directory, and
• your executable is started in that directory.

Thus, your application uses the yourexecutable.exe.config in the bin or bin\Debug directory, and it is there that ConfigurationManager saves the changes, not in your source code directory. This won't be an issue after deploying your application, because then, changes will go to yourexecutable.exe.config in the deployment directory, which is what you want.

Ite

And if you're running in debug mode, it will be yourexecutable.vshost.exe.config – Alkalify

Great explanation! Since yesterday I've been wondering why the configs are not saved in the original App.config file until I read this. Thanks! – Taraxacum

You are better off with your own file, then you have full control over it. The fact that a question had to be raised here highlights that the built-in settings file is poorly designed. Another issue is that the name is the same as the exe with a config extension. The annoying default of windows to not show file extensions means your config file shows up on customer site looking like an exe file. – Bornholm

Answer 3

Further to Appetere's comment on the second answer:

Also note that if you're debugging (and haven't disabled the vshost process), then when your application stops, yourexecutable.vshost.exe.config will be replaced with yourexecutable.exe.config again.

So once again, you may not see any changes you made afterwards! (If you stop at a breakpoint whilst debugging and look in the file after making your modification and calling refresh section, you'll see your changes).

This is very confusing if you are debugging a program which looks for a setting and, if not present, writes it. Even if you're forewarned against expecting the the setting to be there the second time you run the program, one might expect it to be there AFTER the first run of the program and BEFORE the second run ... alas!

It's nothing to worry about since it all just works when the application is deployed or started directly from bin as others have already stated...

But it's possible to fall into a 'trap' though if you're debugging your program and decide to use Application Settings for the first time, and to avoid hand-writing the XML you decide you'll start from code and get the program to write a setting... to get all that stuff, then maybe add several more.

Manno