I know it is a good idea to store configuration data in app.config (e.g. database connection strings) instead of hardcoing it, even if I am writing an application just for myself. But is there a way to update the configuration data stored in app.config from the program that is using it?
If you use the Settings for the project, you can mark each setting as either application or user.
If they're set as user, they will be stored per-user and when you call the Save method it will be updated in the config for that user.
Code project has a really detailed article on saving all types of settings.
app.config isn't what you want to use for user-tweakable data, as it'll be stored somewhere in Program Files (which the user shouldn't have write permissions to). Instead, settings marked with a UserScopedSettingAttribute will end up in a user-scoped .config file somewhere in %LocalAppData%.
I found the best way to learn this stuff was to mess with the Visual Studio "Settings" tab (on your project's property pages), then look at the code that it generates and look in %LocalAppData% to see the file that it generates.
Related
I have a windows application. I am writing all user specific settings into user.config.
Now in a new scenario, whatever changes one user does it should reflect to all the users.
For that purpose I thought of writing the settings into app.config through
Properties.Settings.Default.p1 = value;
Properties.Settings.Default.Save();
And every user read the updated default value after
Reset();
But what ever I do…it still writes to user.config not to app.config
From my experience, the Settings class cannot be used to modify default setting values for all users. In this situation, I modify the app.config directly using the classes in the System.Xml namespace. It is not ideal, but I have not found any other way to do it.
There are a couple things to keep in mind when modifying your app.config file:
If your program is installed in the Program Files folder, you may need to run your application as an administrator in order to save changes to the file. It will depend on how your security is configured.
If you change the namespace of your Settings class, it will change the structure of your app.config file, so you would need to update your code to account for the new XML structure.
See this MSDN article for more information about application and user scoped settings:
http://msdn.microsoft.com/en-us/library/8eyb2ct1%28v=vs.110%29.aspx
I have the settings file in C# where I store the configuration parameters. So, I build the solution and install it in the system. The application creates an XML file user.config consisting of all the configuration parameters in :
%userprofile%\appdata\local or %userprofile%\Local Settings\
I made changes to the configuration through the application and save it by issuing the command
Properties.Settings.Default.Save();
When I restart the application, the configuration consists of the default values and not the updated values.
Any idea if I am missing something here.
%userprofile%\appdata\local or %userprofile%\Local Settings\
This is what is fundamentally wrong about the question, this is not where the user.config file is stored. The LocalFileSettingsProvider class (the default settings provider class) stores the user.config file in a directory with an unspeakable name, like C:\Users\username\AppData\Local\WindowsFormsApplication1\WindowsFormsApplication1._Url_twchbbo4atpsvjpauzkgkvesu5bh2aul\1.0.0.0
The twchbbo4atpsvjpauzkgkvesu5bh2aul part of the name is produced by a hashing function that combines the program install location, program name, [AssemblyCompany] and [AssemblyProduct] to ensure that the directory is unique and will not clash with the user.config of another program. And appending the [AssemblyVersion] so that different versions of the program won't clash.
You'll need to diagnose this problem by first finding the right user.config file back. Start from the %appdata%\Local or %appdata%\Roaming directory. Ensure that the Save() method actually saves, it won't if no setting was assigned a different value. Use SysInternals' ProcMon utility to double-check all assumptions, you'll see your program accessing the file in the trace.
What is the Scope of your settings? You cannot change Application Scoped settings like that from code.
Take a look at the settings designer.
You can read more about settings scope here.
I'm wondering if there is a way to create settings in a config file for individual programmers. The situation I'm encountering is that there are some programmers who want settings turned on and several that want them turned off. Our config files are in SVN source control, so using a shared config file means we are always overwriting each others settings. We are doing this for an ASP.NET web application project. My initial thoughts would be to create a config file outside of source control, but how do I make it so that each programmer has his own copy?
Here is some further clarification. We have a link in the main web.config file that points to an environment-based file (e.g. file used for dev, staging and live).
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings configSource="EnvironmentConfigs\appSettings.config" />
...
</configuration>
Inside the appSettings.config file, we have settings for dev, staging and live. What I'd like to do is create another config file called user.config and have the individual programmer settings staored there (not in source control of course). What do I need to do in order to have visual studio read from this new file?
The settings file does not need to be versioned in SVN, or each developer can select their settings file to not be overwritten or committed. See the SVN settings file, it could even be added as a global ignore.
Each developer can set up their own build congifuration in Visual Studio. This build configuration should be linked to a build script, which replaces sections of the Web.Config/App.Config/*.Config files specifically as the developer wants.
This way, when they want to make changes to the config files to suit themselves, they should change the replacements in the build script rather than changing the config file directly.
This article covers some of the points i've mentioned: http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-with-teamcity-deployment-projects-amp-svn
Remove the config file from source control and set the svn:ignore property on it. Then it won't be committed. Then, also create another file, like, Production.web.config, that has the production values in it, so you still keep those around too.
That's what I do!
Don't commit config file changes unless they are new settings that to be sent to everyone.
Otherwise, checkout, edit, and leave it checked out. You'll know if someone else has added/modified the file when you get latest version. At which time you merge your settings with their changes, but leave it checked out on your machine.
We do not store application configuration files in source control. Instead, in source control, we store a configuration file template, usually named something like web.config.template. Each developer has their own 'values' file, usually named web.config.values-bem for instance. Each developer also sets up a post-commit hook which takes the template file, and processes it, replacing 'variables' with their values from the specified values file.
For instance, my config values file has the following definition in it:
DB_SERVER=.\SQLEXPRESS
In the web.config.template file, this exists:
connectionString="server=#DB_SERVER#[DEV1];Persist Security Info=True;Password=#DB_PW#;User ID=#DB_USER#;database=#DB_NAME#;Enlist=false;Max Pool Size=100" />
So when the process runs (a python script), it replaces all instances of #DB_SERVER# with the setting I have in my values file. The template script allows for default values to be specified right in the template as well, so you can make changes to the template file and not break other developers' environments (usually). (The default values are next to the variable, in square brackets.)
This solution allows each developer to have their own settings, but still have a web.config.template file that's versioned, and each developer avoids 'inflicting' configuration changes on other developers.
This works well for us. If you want to use the same scheme, you can check out the code for it on my github: https://github.com/bmontgomery/FileReplace. I can help you with the hook scripts as well if you're interested in that.
I am working on a software and want to create a configuration file for my application to store configurations that will be used at runtime. I have seen some software use a config.xml file to achieve this. The configuration file I want to use will have:
Cache folder location
Color scheme
Option to toggle caching
How to go about this? I am working with WPF.
In Visual Studio, add an "app.config" to your project. When you build your application, this will create an AppName.exe.config file, where AppName is the name of your executable. This is an XML config file that can contain your settings.
If theses options are user-specific, don't use app.config - that's for global application settings and you will clobber other users' settings. I'm bringing this point up because you mentioned caching options in your question, and in some applications, the choice to cache or not to cache is at the user level.
Instead, I would recommend that you create a domain object to store the configuration settings to, and serialize the object to a local folder in the current user's isolated storage folder.
When the application starts up, just look into the current user's isolated storage folder, confirm the serialized file exists, and deserialize back to the domain object.
as you are in WPF world, you also can use App.XAML for defining and using color schemes
Use standard .NET settings framework.
More details here: How is the logic behind storing program setting in text file like 'config.cfg'?
Also this will help http://msdn.microsoft.com/en-us/library/aa730869%28v=vs.80%29.aspx.
Although this article is a little old, not much changed since then in this realm.
I've seen this solution proposed, but doesn't seem to work for me:
Configuration oConfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
oConfig.AppSettings.Settings["PreferenceToRemember"].Value = “NewValue”;
oConfig.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("appSettings");
It successfully changes the value in memory, but does not save it back to the config file.
I'm trying to do this in a Wpf app, if that makes any difference.
Or is there a preferred way to save user settings to a file?
If your app is installed in \Program Files\ then it may not have permissions to write to the file. Generally, app.config files are modified by hand (in my experience, at least). If you want to persist user preferences, you should look into a .settings file as these are created in the %appdata% (or %localappdata%) directory, which is under the user's directory.
My guess is that using OpenExeConfiguration does not actually open the associated file. For example, you could be running from a XAP, where there would still be a .exe.config inside the .xap, but it doesn't map to an actual file on the filesystem.
You could probably check this by seeing if oConfig.HasFile is true or not.
If my guess is correct, then you'll need to use the OpenExeConfiguration(string) overload; the sample on the MSDN page has a reasonable way to get the right filename, although my first instinct was instead to try System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase.