ConfigurationManager doesn't save settings
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
{
Mes开发者_JAVA技巧sageBox.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?
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
When you run your application with F5,
- your code is compiled,
- the executable is copied to the
bin
orbin\Debug
subdirectory of your source code directory, - your
app.config
is copied asyourexecutable.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.
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.
精彩评论