My.Settings.Upgrade doesn't upgrade?

[Bob Altman]

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

 

[Bob Altman]

It turns out that there is one more crucial point that I didn't think of:
Each new release of my app is installed into a different folder! (We have a
requirement to be able to have multiple versions of the app installed
side-by-side.) So, the My.Settings magic probably considers each new
release a different app because it comes from a different location.

That leaves me with the question of how to tell My.Settings that it should
consider any version of my app to be the same app even if its location has
changed. Is that possible?

TIA - Bob

 

[Hongye Sun [MSFT]]

Hi Bob,

Thanks for your post.

This issue is probably caused by "Each new release of my app is installed
into a different folder". I will explain it in detail:

1. How does My.Settings.Upgrade() determine a previous version of the user
settings
In My.Settings, it delegates the upgrade job to LocalFileSettingsProvider
(http://msdn.microsoft.com/en-us/library/system.configuration.localfilesetti
ngsprovider.aspx), which has been specified in
My.Settings.Providers("LocalFileSettingsProvider").

Within LocalFileSettingsProvider, it follows the logic below to find
previous version typically. In order to explain it more understandable, I
will use one example that you provided.
My Profile
Application Data
My Company
MyApplication.exe_Url_gibberish
1.0.0.0
1.1.0.0
We suppose that our application is running as 1.1.0.0 version.

When upgrading:
a. LocalFileSettingsProvider will look for current application's user
config path from AppDomain.CurrentDomain.Evidence. (I will explain it later)
b. The found path looks like "%AppData%/My
Company/MyApplication/MyApplication.exe_Url_gibberish/1.1.0.0/"
c. It goes up to its parent folder "%AppData%/My
Company/MyApplication/MyApplication.exe_Url_gibberish/" and go through all
its subfolders.
d. It finds the biggest version number which is less than 1.1.0.0 and find
the user.config file under that version. (Here the previous version is
1.0.0.0)
e. It merges all the settings from previous version into current one.

2. How is application config path determined?
a. There is an internal class named "ClientConfigPath" who does this
determination.
b. It gets host information by calling
"AppDomain.CurrentDomain.Evidence.GetHostEnumerator()"
c. If the application is strong named, it uses the strong named public key
and assembly name to build hash code and the set the folder name as
"MyApplication.exe_StrongName_xxxxxxxxxxxxx", where "xxxxxxxxxxxxx" stands
for hash code.
d. If the application is not strong named, it will use its evidence URL
(http://msdn.microsoft.com/en-us/library/system.security.policy.url.aspx)
which usually is the application install path, to construct a hash code.
The folder name looks like "MyApplication.exe_Url_gibberish".
So the conclusion is that when the exe assembly is strong named, the folder
name depends on its public key. Otherwise, it depends on the application
install path.

* Solution *
After knowing how My.Settings.Upgrade() works, we can find that making exe
assembly as strong named assembly is one solution to the this problem.

Please have a try of it and let me know if it works for you. Thanks.

Regards,
Hongye Sun ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Bob Altman]

Thanks Hongye, signing my application solved my problem!

Bob

 

[Hongye Sun [MSFT]]

You are welcome, Bob. I am glad that my suggestion helps you.

Have a nice day.

Regards,
Hongye Sun ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
 

This posting is provided "AS IS" with no warranties, and confers no rights.