tags:

views:

148

answers:

3

*Or: "Where the %#%¤/ am I supposed to store my settings?"

Why is the product version number included in the Application.UserAppDataRegistry registry key? I think it's really annoying.

Doesn't this just encourage developers to stick with version number 1.0.0 forever, since changing the version number will cause the user to loose all settings (unless extra effort is made)?

If I strip away the version number, it will of course work "better" (the way I see it), but the framework still creates the registry key with the version number.

What am I overseeing? Ekeforshus

A: 

I reckon the version number is in there so that users can install 2 versions of your application and run them side-by-side. Other than that , i dont see the rational of losing all the configurations when a version number has changed.

Personally , i usually use config files to persist configuration information and avoid the windows registry

Andrew Keith
If I really need side-by-side support, I'd rather do the extra work THEN instead of the other way around... :-(But you get the same problem with Application.UserAppDataPath? And writing to the application's installation directory will cause trouble under Vista... so where do you place your config files?
danbystrom
I place the config files within program files in a folder named after my application. Developers often store the config files in their debug directories, so that they can have a different config. The customer is advised to backup the program files so that if they suffer config failure, they can restore quickly before calling tech support.
Andrew Keith
I think that's whet darbystrom was talking about when he said that it would cause problems under Vista. Specifically, if your user doesn't have admin rights, when s/he runs your program, it will not be able to save their configuration when the config file is located under Program Files. Better to put it under %ALLUSERSPROFILE% if your configureations are on a per machine basis or %LOCALAPPDATA% if they're on a per user basis. Ditto for any other files that your app modifies at run time.
RobH
A: 

This allows you to change what settings are stored from one version to another. If version 1.0.0 has setting "foo" and in version 2.0.0 you split what's in 1.0.0/foo to 2.0.0/foo and 2.0.0/bar you are still covered. Your installer/configuration wizard would need to check for settings branches of previous versions and convert them to the settings of the new version. Note, though, that you need to directly access the repository to get the previous versions.

Frank Ames
It really should be the other way around. If I release a bug fix as 1.0.1 I shouldn't have to go through all this trouble. I don't want to create a new installer for this. And what should I do with the old 1.0.0 settings? Delete them or leave them in the registry for eternity? What if I delete them and the user realises that my 1.0.1 wasn't satisfactory and descides to keep using 1.0.0 until I can give him a 1.0.2? I think someone at M$ wasn't thinking clearly here.
danbystrom
A: 

I think this is what IsolatedStorage is intended for. Here is some sample VB code:

Public Shared Sub SaveGridLayout(ByVal grd As Infragistics.Win.UltraWinGrid.UltraGrid, ByVal sPrefix As String)
    Dim isf As IsolatedStorageFile = IsolatedStorageFile.GetUserStoreForApplication()
    Dim userDataFile As IsolatedStorageFileStream = New IsolatedStorageFileStream("ClearTrac" + sPrefix + ".dat", FileMode.Create, isf)
    grd.DisplayLayout.Save(userDataFile)
    userDataFile.Flush()
    userDataFile.Close()
End Sub

If use use the GetUserStoreForApplication, it is not version specific.

Decker97