Develop Reference

Update user settings from outside the application

I have a C# application (a VSTO office addin) running on clients' machines, and I need to make a setup project or any other EXE that can overwrite and update the user settings in the user.config files with my own values.
It seems that I can't know exactly where the user.config is- it seems to create different folders under AppData\Local\Microsoft_Corporation with different names and numbers. I can try to iterate every subfolder I find but I was hoping for something better.
I can't get the path by using ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal) because I'm not inside the application, and I tried it inside the application and it actually returned a different, wrong path.
I can overwrite the app.config because I know where the application sits, from the registry, but overwriting it doesn't change user settings if the user settings were already saved in user.config too.
Can I force .NET to write the user.config into a predetermined location and store it in the registry, so I would have it for my setup?
Any ideas how to complete this objective? Is there some common practice for this? Thank you

Don't update the settings from your installer. The installer can save new options locally (HKLM, local folder, etc.) visible to every local user. When your addin is loaded, it can grab the new settings from that location and update its local settings as necessary.

Where to store user preferences for a C# Windows app

Can anyone provide a best-practices example for where to store user preferences for a C# Windows app?
So far I've heard a number of options:
Some people are saying to store it in
SQLite. Is SQLite bundled with .NET
2.0 and immediately available for use to me?
Others have said to use the built-in
Application Settings... but I've
heard that the per-user settings here
disappear if you upgrade the app (an
obvious problem).
I've also considered just storing it
in a .xml file somewhere on disk...
but where it the "correct" place to
store that .xml file for the user?

SQLite is not included with .NET2, but you could ship it with your application
The built-in settings system works fine for simple apps - you do need to add a couple of lines of boilerplate to deal with version changes but it's not complicated.
You could put your xml file here:
Environment.GetFolderPath(
Environment.SpecialFolder.LocalApplicationData)
There is a lot of 'it depends' about your question, as you don't say how much of what types of data you need to store, nor if you have any other reasons to care where it goes.

The per-user settings "disappearing" can be solved thus: .NET ApplicationSettingsBase Should I call Upgrade() every time I load?

Storing user application settings in isolated storage seems to be a best practice.
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage(v=vs.80).aspx
Storing settings as an xml file is perfectly fine.

How to keep user settings on uninstall

I'm using .NET user settings feature and I'm facing a problem.
When the application is uninstalled, then installed back, the user settings are lost.
I understand it's by design, and I want to be able to give the choice to the user in the installer.
Could you please give me some pointers to articles or documentation that will helps me?
Thanks a lot

.NET User Settings are not removed on uninstall. In fact the settings of all previous versions of the software are preserved in Local Settings directory.
When the new version is installed, a new version of the settings is created and default settings are used.
To ensure your application will merge new settings with previous configuration, you have to call Settings.Default.Upgrade() method.
So the solution is to manually remove settings on uninstall if we don't want to preserve them. Since what I needed was preserving previous settings, all I do now is creating a new setting called UpgradeRequired with true has the default value, then add this code at application startup:
if (Properties.Settings.Default.UpdateRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpdateRequired = false;
}

You could possibly write the settings you wish to save out to the registry or write them as an XML file to a location that won't be impacted by the uninstall.

If you want to keep using User Settings i would suggest writing a custom installer class, and implement the onUninstalling method, to go find the file and copy it to another location known to the onInstall method of your custom installer. So that the next time the installer runs it could find the file.

I don't think you want to actually persist data on the users machine after an uninstall. Leaving files around is an evil practice, a big no-no. You should expose a feature in the application itself to either export those settings to a location of their choice and to then import it again after re-installing the app or to synchronize those settings onto a server so they're automatically available upon re-install, etc. On an uninstall you should leave no trace behind.

how to store settings for deployable c# application?

I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.

Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.

I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.

The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].

If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.

The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).

Best place to store configuration files and log files on Windows for my program?

I need to store log files and configuration files for my application. Where is the best place to store them?
Right now, I'm just using the current directory, which ends up putting them in the Program Files directory where my program lives.
The log files will probably be accessed by the user somewhat regularly, so %APPDATA% seems a little hard to get to.
Is a directory under %USERPROFILE%\My Documents the best? It needs to work for all versions of Windows, from 2000 forward.

If you're not using ConfigurationManager to manage your application and user settings, you should be. The configuration toolkit in the .NET Framework is remarkably well thought out, and the Visual Studio tools that interoperate with it are too.
The default behavior of ConfigurationManager puts both invariant (application) and modifiable (user) settings in the right places: the application settings go in the application folder, and the user settings go in System.Environment.SpecialFolder.LocalApplicationData. It works properly under all versions of Windows that support .NET.
As for log files, System.Environment.SpecialFolder.LocalApplicationData is generally the place that you want to put them, because it's guaranteed to be user-writeable.
There are certainly cases where you wouldn't - for instance, if you want to write files to a network share so that you easily can access them remotely. There's a pretty wide range of ways to implement that, but most of them start with creating an application setting that contains the path to the shared folder. All of them involve administration.
I have a couple of complaints about ConfigurationManager and the VS tools: there needs to be better high-level documentation than there is, and better documentation of the VS-generated Settings class. The mechanism by which the app.config file turns into the application configuration file in the target build directory is opaque (and the source of one of the most frequently asked questions of all: "what happened to my connection string?"). And if there's a way of creating settings that don't have default values, I haven't found it.

Note: You can get the path to the LocalApplicationData folder in .NET by using the following function:
string strPath=System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData);

For application settings - use System.Environment.SpecialFolder.ApplicationData - this is where a roaming profile data is stored, so it allows your user to log and work from different machines in the domain.
For log files - System.Environment.SpecialFolder.LocalApplicationData

The accepted answer notes that for log files the following is a good spot.
System.Environment.SpecialFolder.LocalApplicationData This equates to a path of C:\Users\[User]\AppData\Roaming which you can see is user specific. Like the accepted answer mentions this is a guaranteed user-writeable location and can be useful for certain situations
However in a web application environment you may be running your application under a network account and you or a coworker may need to try and track down where exactly those logs are going per application. I personally like to use the non user specific location enumeration of
System.Environment.SpecialFolder.CommonApplicationData which equates to C:\ProgramData. Yes, you will need to specify access rights for any folders you create, but it's usually a one time deal and then all of your application logs can live in one happy location.
Additionally, while looking around the Internet, there is a project out there to programatically set write access to folders you create within CommonApplicationData, Allow write/modify access to CommonApplicationData.

To be honest %appdata% is still the best place to place your config files and log files, as it serves the purpose of a placeholder to store your application data. It should not be that hard to access, just write %appdata% in explorer and you will be directed straight to your %appdata% directory.

Do not store config files in the application folder, Microsoft has stated this is NOT the ideal location. Windows has been moving towards blocking writing to C:\Program Files\ and you'll find in Vista any application that tries to write here, will fire up a UAC warning.
Windows 7 will allow users to customize what UAC popups they use (expect some power users to block most of them) and your app will fail/freeze if the user never approves this write attempt.
If you use the proper userprofile and appdata variables, then Win 2000, XP, Vista, and Win7 will map the data to the proper write friendly folder, with no UAC popups.

You can use SHGetSpecialFolderPath:
int MAX_PATH = 255;
CString m_strMyPath;
SHGetSpecialFolderPath(NULL, m_strMyPath.GetBuffer(MAX_PATH), CSIDL_COMMON_APPDATA, TRUE);
This will specify the 'special folder path' which you can safely write logs to for windows:
For XP: C:\Documents and Settings\All Users\Application Data
For Vista: C:\ProgramData
Check the MSDN page here: http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx

The best answer depends on the nature of the logs and configurations. If they are program-wide, and don't need to survive uninstallation of the application, then I think they're fine where they are. If the logs and configurations are user specific, or need to survive uninstallation, then they belong somewhere under %USERPROFILE% - %APPDATA% being the 'proper' base directory for this type of thing.

I use the Isolation Storage for configuration. You can also use the Temp folder to store temporary information like log.