Hi all,
In my VB 2005 project I create a setting called UpgradeRequired with a
default value of True, and I include the following code that runs when the
project is launched:
If My.Settings.UpgradeRequired Then
My.Settings.Upgrade()
My.Settings.UpgradeRequired = False
My.Settings.Save()
End If
This code should allow a user to run one version of my app which saves
settings, then run a newer version of the app and automatically have the
saved settings applied to the newer version of the app. But (as you guessed
by the fact that I'm posting this question) it's not working. When I run
the newer version of my app I just get the default values for all of the
settings.
To try to get to the bottom of this, I need to understand what magic
My.Settings.Upgrade uses to determine if there was a previous version of the
app settings. I notice that the persistence mechanism creates a user.config
file in a new application folder for each new version of my app:
My Profile
Application Data
My Company
MyApplication.exe_Url_abcdefg
1.0.0.0
MyApplication.exe_Url_hijklmn
1.1.0.0
However, when I create simple test program that does the same thing, and
just change the file and assembly version numbers between runs, it puts both
"version" folders under the same application folder:
My Profile
Application Data
My Company
MyApplication.exe_Url_gibberish
1.0.0.0
1.1.0.0
So, something that I am doing when I build and install my application in a
production environment is causing the My.Settings magic to think that what
newer versions of my application are a totally different application.
My application consists of a main program and a bunch of strong name signed
DLLs, all of which share the same assembly and file version strings. Each
time I create a new version of my application I create a new, higher version
number and rebuild the whole kit and caboodle with that new version number
baked into all of the assemblies.
One other thing I'm doing is this: Each of the DLLs has its own user-scoped
settings (maintained in the magic My Project -Settings designer). This
seems to work as expected; each assembly "sees" its own settings via
My.Settings.<SettingName>, and all of the settings are persisted in separate
sections of the user.config file.
TIA - Bob
