Can I control the location of .NET user settings to avoid losing settings on application upgrade?

Question

I'm trying to customize the location of the user.config file. Currently it's stored with a hash and version number

%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\ 

I want to it be agnostic to the version of the application

%AppData%\[CompanyName]\[ProductName]\ 

Can this be done and how? What are the implications? Will the user lose their settings from the previous version after upgrading?

Answer 1

I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:

Properties.Settings.Value.Upgrade(); 

From Client Settings FAQ blog post: (archive)

Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?

A: There are couple of reasons why the user.config path is version sensitive.

(1) To support side-by-side deployment of different versions of an application (you can do this with Clickonce, for example). It is possible for different version of the application to have different settings saved out.

(2) When you upgrade an application, the settings class may have been altered and may not be compatible with what's saved out, which can lead to problems.

However, we have made it easy to upgrade settings from a previous version of the application to the latest. Simply call ApplicationSettingsBase.Upgrade() and it will retrieve settings from the previous version that match the current version of the class and store them out in the current version's user.config file. You also have the option of overriding this behavior either in your settings class or in your provider implementation.

Q: Okay, but how do I know when to call Upgrade?

A: Good question. In Clickonce, when you install a new version of your application, ApplicationSettingsBase will detect it and automatically upgrade settings for you at the point settings are loaded. In non-Clickonce cases, there is no automatic upgrade - you have to call Upgrade yourself. Here is one idea for determining when to call Upgrade:

Have a boolean setting called CallUpgrade and give it a default value of true. When your app starts up, you can do something like:

if (Properties.Settings.Value.CallUpgrade) {    Properties.Settings.Value.Upgrade();    Properties.Settings.Value.CallUpgrade = false;     } 

This will ensure that Upgrade() is called only the first time the application runs after a new version is deployed.

i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.