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/
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 use a settings file in my project in addition to a configuration file, and I wish to move away from using the settings file in preference to the configuration file.
The settings file is the default .net application setting mechanism (ApplicationSettingsBase), and my configuration file is a custom class that I serialize and deserialize manually.
I have successfully in the past applied the NeedUpgrade/Upgrade() logic to keep settings from previous versions, but somehow it seems settings are lost non-the-less.
The difference with this project in regards to earlier projects, is that it is deployed using Click-Once.
To work around the problem, I wish to move away from the settings file all together and rather use my configuration file which is stored in a static folder (Environment.SpecialFolder.LocalApplicationData), but I do not know how I best would proceed in managing this migration/change.
Any advice is appreciated.
This may sound like a trivial question, however I have looked over the web briefly and what I found was that app.config is basically an older mechanism for storing Application key/pairs of data for the application.
What I want to know is there any reason we (as .NET developers) would opt to use app.config over a Settings file ?
-Can someone please provide some pros and cons on both so we can use them properly.
thanks again
App.config for desktop applications and Web.config for web applications are part of .NET configuration system. Primarily they are used to control .NET framework settings in respect to our application. These are such configuration settings as substitutions of versions of assemblies (section <assemblyBinding>), substitution of .NET framework version (<startup>) etc. (see msdn for the full app.config schema.) One section is dedicated for custom settings of application developers (<appSettings>). There is also a possibility to create custom sections. So, when we need to store settings we can either piggy-back on the app.config or create our own separate configuration files.
Here are pros and contras of using app.config:
Pro: There is already a standard API in .NET to read settings from appSettings section. If you only need just a couple of config settings, it is much easier to use this ready API than to develop and test your own class to read your config files. Also, app.config file is already included in VS project for you.
Pro: There is a standard hierarchy of machine.config/app.config. If you plan such settings that can be set machine-wide and overridden or left as-is for individual applications, you should use app.config.
Pro/Con: App.config is cached in run-time. If you anticipate updates of it while your application is running, you need to specifically request refresh of certain section of config file. For web.config the web app is automatically restarted when something is changed in the file. This is quite convenient.
Con: app.config is stored in the same directory as your .exe file. Normally it will be in a subfolder of C:\Program Files. This directory is extra protected in Windows 7 from writing. You need to be member of Administrators group to write there and if your UAC (User Access Control) level in Control Panel is not set to 0 (which normally is not), you will be asked by the OS to confirm writing to c:\Program Files. So, users without Administrator rights will not be able to change configuration in app.config. Same goes for changing your settings programmatically: your application will get exception when attempts to write app.config if it runs not under an admin user on Windows 7. Your own config files usually go to C:\ProgramData\ or c:\Users subfolder (on Windows 7). These locations are friendlier to writing by users or programs.
Con: If user edited your app.config file and accidentally corrupted it, the whole application will not start with some obscure error message. If your separate config file is corrupted, you will be able to provide more detailed error message.
In conclusion: app.config gives you easier (faster development) approach, mostly suitable for read-only settings. Custom settings file gives you more freedom (where to store file, validation/error handling, more flexibility with its schema) but requires more work during development.
You have it backwards, the settings file (or ini file as they were originally called) was the mechanism used to hold application settings (key/value pairs) prior to Windows 95. With the release of Windows 95 it was recommended that application settings be moved into the Windows Registry (which proved problematic since if you screwed up your registry your Windows may no longer be able to start).
The .config file came into play with .Net. The XML format allows more dynamic and complex settings configurations than simple key/value pairs.
The modern user/settings file is an XML extension of the .config file (settings that can override certain settings in the .config under specific conditions).
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.
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.