I want to save some settings on a config file for future use.
I'm trying to use the regular code that I see on all the tutorials -
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings["username"].Value = m_strUserName;
// I also tried -
//config.AppSettings.Settings.Remove("username");
//config.AppSettings.Settings.Add("username", m_strUserName);
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("appSettings");
Now - I can see that on runtime - the file "...vshost.exe.config" on "Debug" folder is changes, nut when I close my application - all the changes are deleted.
What can I do?
To test using the normal exe's config file un-check the box for "Enable the Visual Studio Hosting Process" in the "Debug" tab in the project properties menu. That will make visual studio no-longer use the vshost.exe file to launch and the correct config file will be used.
When you deploy your application to your end users, there is no vshost.config.
Your changes will be applied to the real exe.config. So you don't have to worry for this.
When you build your application in a debug session, the app.config file, present in your project, gets copied over to the output directory. Then this config file gets copied to vshost.config as well. In this way the contents of app.config overwrites any changes made during a debug session in the vshost.exe.config.
However let me say that writing this kind of information into an application config is a bad practice. The configuration file should be used only to store permanent configuration that usually don't change during the lifetime of your application. Connection settings, for example, are valid info to store there because you normally don't change these and you don't want to hard code them.
Settings like the user name should use user.config instead. This config is per-user/per-app and allows read/write access.
Related
I'm creating an application and I make use of Properties.Settings to store the settings.
However, let's say my application is on the desktop of the user and is called Program.exe, now, when the user copies this executable and places it somewhere else or even renames it, all settings are gone.
Why is C# doing this? Is there any way this can be turned off while pertaining the user scope? I don't wish to use the application scope since multiple users can be sharing the same computer.
The settings are likely stored in {appname}.exe.config which apparently is not being copied/renamed with the executable. Either copy the executable with the file, hard-code them in the application, or find another mechanism to get/set app settings (like the registry).
The application will look for these settings in a file titled {appname}.exe.config. If the executable is renamed (without renaming the .config file) or copied to another location without copying the .config file along with it, the application won't know where to look for their settings so they will be blank (unless you set a default value in the app).
You can "hard-code" default settings by putting a value in the Settings.settings "file" in Visual studio (which effectively adds the default value as an attribute to the setting).
Another option would be to hard-code the values directly in the source code. I'm NOT recommending this approach as it hinders the ability to change that value, but if you want to be able to deploy the app by just copying the EXE (and nothing else) then it is an option.
See http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx for details.
The settings (and their location) when using Properties.Settings is determined by the Scope setting of the particular setting.
Settings that are Application scoped are in the app.config file (renamed at compile time to .exe.config - these settings are read only at run time), and settings that are User scoped are saved in a user.config that is tied to the user's profile on the machine (these settings are read/write at run time). By properly scoping your settings you should be able to avoid this type of problem.
Settings are stored in the user profile (under C:\Users[UserName]\AppData\Local), these settings are under folders that have the application name and also have an identifier of the location of the exe file they refer to, for example: MyApp.exe_Url_hpvvra0rj4y03ebpz3cfmzsrcpczat11, refers to the executable under Program Files, if i move or copy the exe and run it, it will create another folder with another URL (MyApp.exe_Url_vqzsq0spwewydv3wrnebtqji24nwuboe, for example), i haven't find a way to avoid this but a good workaround is to copy the settings from another config file, just note that this method is not foolproof as you have to choose the right file to copy the setting to and if you expect your exe to be copied or moved constantly this will be a hard task.
Another workaround is to simply create your custom settings class and put the file anywhere your application can find it and don't realy on the built in settings on .NET.
I have settings that were originally scoped as User settings. I notice that the main .config that lives in the same directory as the assembly is being ignored by .NET. If I change any setting it still always ends up with the default values at run-time. I was unable to find a copy of the config file in User AppData. I changed the settings' scope to Application and yet .NET is still ignoring the config file.
Where is the file it's trying to load instead? How can I get it to only use the .config file in the assembly's directory?
If you are using visual studio to run your application, visual studio regenerates the settings file every time you complete a recompile.
So if you change your settings within the application and rebuild & launch within visual studio, the settings file will revert to what values are stored in the visual studio project.
If you use Configuration manager to read settings from config file, it has to load data from appname.exe.config file. Try this code (you have to add reference to system.configuration assembly)
System.Configuration.ConfigurationManager.AppSettings["settings-name"];
My ClickOnce app includes an app.config file, which the app does modify according to the user's preferences. It appears, though, that every time my clients get a new version of the app, the app.config file gets reset to its original state.
Is there any way to preserve the app.config file between ClickOnce updates?
The app.config is used to store application configurations. For user custom configurations you should be using a .settings file.
The only way I know to keep the user app config is to save a copy of the file before publishing and, post publishing, replace the
publish_dir/version_dir/app.config.deploy
with the copy.
I would separate the configuration settings from the application cache. We rolled our own class for storing and updating config values rather than use the built-in ones.
http://robindotnet.wordpress.com/2009/08/19/where-do-i-put-my-data-to-keep-it-safe-from-clickonce-updates/
I thought it should be a config file, but cannot find it.
thanks
The whole config file location can be a bit slippery. Depending on whether or not its a "user" setting or an "application" setting, it will go into a different file. Some settings can even come from your "machine" config (Like in the case of ASP.NET). Instead of guessing where everything is, I find it much more useful to ask .NET where it is looking for these files. Roughly:
//Machine Configuration Path
string path1 = ConfigurationManager.OpenMachineConfiguration().FilePath;
//Application Configuration Path
string path2 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None).FilePath;
//User Configuration Path
string path3 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;
App.Config
This is what gets added to your project. The build process will name it [myproject].exe.config. This holds the (mostly) read only application settings and the application-level defaults for user-specific settings. Application level settings are difficult to programmatically change their values. Application level setting properties will only have "get" defined. The intention is: if your setting is for all users of the application, then a manual edit (or the installer) should set them. If it changes per user, then make it a per-user setting.
Binary Default Settings
Your application will run without its [myproject].exe.config file. To do this, the binary has its own version of the file "stored". This is useful in some ways, but can be confusing. If you have a .config file in the wrong place or with the wrong name, .NET reverts to the "binary defaults". It can cause the appearance of not being able to affect the settings by changing the config file. Use the method above to know where the .config REALLY goes, or face the wrath of the binary default settings.
User.Config
This is generated the first time you "save" your Default.Settings object with a "per-user" setting. This file is saved in the user's profile path in a location based on your project's name, version, operating system, and some other dark .NET magics. The properties for these settings are readable/writeable. They are designed to be easily set and then saved with a single call.
Pulling it Together
So where do my settings go? The answer is that potentially many files are joined together to get the "Active set" of settings. App.config and user.config settings are the basic blocks, but there are machine.config settings, and then there are dependency assembly settings that can further complicate things...but thats another topic entirely.
The real truth of config files is spread across a lot of ugly cases and details. However, with a little knowledge about how they are joined together, it is a fairly useful system. Especially if you realize you can databind to these settings ;)
If you're talking about .Net settings, then they will normally be in a .config (xml) file in the same directory as the application. When you save them, however, a local copy gets saved in to a user writable folder (typically C:\Users\username\AppData\Local under Vista). Under XP, look in the Documents and Settings folder.
The .Net application uses this file in preference to the 'default' one in the application directory.
Hope this helps.
On Windows XP, it's stored in a file called user.config in a subfolder of:
C:\Documents and Settings\username\Local Settings\Application Data
http://dotnetproject.blogspot.com/2006/08/where-is-userconfig-file-located-in.html
Are you referring to the .settings file in your application? When you add values to that file, an app.config file gets created for you. You should be seeing it in your solution explorer.
I'm deploying an application using ClickOnce, the problem is that the configuration file (xxx.exe.config) is not embedded in the package and there is no option to include it. Another problem with the config is that When I'm trying to manually write it to the directory where it is delopyed (Environment.CurrentDirectory) I'm getting an exception - I have no permissions to do that.
Any ideas on how to deploy the app along with the configuration file? (and to make it writable, because the applications during ti's runtime alters the config values.)
Thanks in advance
You can also change build action for files that you want to include in ClickOnce deploy: Properties for a file → Build Action → set to "Content", this will add the file to the list of Application files in Publish project options.
If you need to publish a file from a referenced project, I didn't find a better solution rather than to Add → Existing Item → On "Add" button, select "Add as Link", then set action to Content and check the list of published files.
The config file should get published automatically; if not, ensure that it is configured to copy to output, and (if that fails) check the publish files (project properties -> publish -> application files; the config file should be marked as "include (auto)" or "include").
You shouldn't attempt to update anything in the app install directory. That is a bad idea generally (since you can't assume you can update "program files" unless you're an admin), but the same holds true for ClickOnce too.
Just create a settings file with some user settings; these will be saved in the user's profile, so can be updated reliably. You can't edit the files deployed via ClickOnce; even if you had access, it would (by default) break the hashing function, and it will refuse to load them. You can turn off the hashing, but... this still isn't a great idea.
When you click on the Properties of your project and go to the Publish tab of the project's properties, click Application Files... then check the 'Show All Files' checkbox. You should see an option to choose your applications config file from there.
In my experience the <*>.exe.config file is usually set to include automatically however.