Version upgrade problems with settings

[GeneralZaphod]

All,

My team and I have been fighting a Settings problem for a long time with no resolution. Essentially, most of the time when the build changes, even slightly, an upgrade of the settings file results in the settings being some older, seemingly random version. This is very clear because we see things we know where set some way before, but are no longer. Based on observation over time, this randomness "may" result in the most recent being used. Sometimes it is many revisions back. This is absolutely confounding. I have searched over and over looking for answers. Originally, we were calling upgrade every time, but found that we could add a version check and only upgrade when the version changes. So, when we change versions we do:

if (GetLastRevision() != GetAppVersionString())
{
Settings.Default.Upgrade();
SetLastRevision(GetAppVersionString()); // Now that this will save all settings too.
return true;
}

I so hope somebody has a fix for this. It is really killing us. Your help is super appreciated!!!

-GZ

 

[NoUserHere]

Is this an updater application? Are you publishing to git or some other repo provider? How are you managing your versions?

I feel there is not enough information to help you here, and I can't say I've ever experienced something like this before myself.

 

[GeneralZaphod]

Is this an updater application? Are you publishing to git or some other repo provider? How are you managing your versions?

I feel there is not enough information to help you here, and I can't say I've ever experienced something like this before myself.

Hi, thanks for asking. We do publish to a private git repo. This is just a test application that uses the basic .net settings file as a way to store user configurable settings. Builds are currently managed manually using a local build, and an inno compiler to perform the builds. I am already considering moving to a ADO hosted environment for more managed builds. Is it possible that Inno maybe causing some hosification of the settings upgrade?

 

[NoUserHere]

Is it possible that Inno maybe causing some hosification of the settings upgrade?

I don't think so. I've just done a bit of digging and it seems your issue is fairly isolated. So I'd be more incline to consider other possibilities, like perhaps one of your team doesn't have up-to-date repos and is maybe pushing old files out to git. If whoever compiles your application pulls in all the files you and your team edited, and the person compiling it maybe using an out-of-date settings file submitted by another team member. Is that possible? I'd probably look a little closer at how your files are distributed between your team. And if you can rule that out... well your guess is as good as mine really.

 

[Skydiver]

I'm hoping that the code on post #1 is pseudo code and not real code. I say that because in general, you should only upgrade if the app version is greater than the previous version in settings. If the current app version is older than the settings file version, you should simply abort (unless your settings are always backwardly compatible).

 

[GeneralZaphod]

I'm hoping that the code on post #1 is pseudo code and not real code. I say that because in general, you should only upgrade if the app version is greater than the previous version in settings. If the current app version is older than the settings file version, you should simply abort (unless your settings are always backwardly compatible).

That is exactly what it is. I save the current version in the settings and compare to the current version.

 

[GeneralZaphod]

I don't think so. I've just done a bit of digging and it seems your issue is fairly isolated. So I'd be more incline to consider other possibilities, like perhaps one of your team doesn't have up-to-date repos and is maybe pushing old files out to git. If whoever compiles your application pulls in all the files you and your team edited, and the person compiling it maybe using an out-of-date settings file submitted by another team member. Is that possible? I'd probably look a little closer at how your files are distributed between your team. And if you can rule that out... well your guess is as good as mine really.

I should have mentioned this before, but this happens when just changing and running from VS too. Anytime I make the slightest change that causes the version to change, even just locally, I see this occur most of the time. Also it is definitely an old settings file. I have noted it seems that the app saves old versions for you, but I haven't dug to see how that works. I am just sure it was something I used before but had changed. This is most obvious in that I save a "last file path" for something which changes very often, so when it doesn't automatically load the most recent one I worked with, it is very obvious. I am sure the other settings values were matching that older version too simply in the way we use it.

 

[Skydiver]

Is there any chance in your AssemblyInfo.cs you have one or more asterisks like:

[assembly: AssemblyVersion("1.0.0.*")]

If so, then every time you compile, the assembly version will change.

 

[GeneralZaphod]

Is there any chance in your AssemblyInfo.cs you have one or more asterisks like:

[assembly: AssemblyVersion("1.0.0.*")]

If so, then every time you compile, the assembly version will change.
[/QUOTE]

Hi again, thank you. Yes, that is exactly correct, my understanding from all the searching about the topic is to upgrade the settings when the assembly changes. This code hand-checks the version for change. I would agree that removing the .* would prevent this when doing local builds, but when we release we rev the other 3 (of 4) numbers in the assembly, which seems would cause the same problem. Since we don't actually have a build server that changes the 4th .* (like you would a build number) it does become rather worthless. In the case of my users since I always rev the assembly version, they always experience this on the released code, presumably as a result of the .Upgrade itself. Are you also saying that an end user going from 1.2.3 (i.e. no 4th) to 1.2.4, performing the upgrade, would worth just because there is no 4th value? I will try it as it is definitely worth the try. Thanks again.

 

[NoUserHere]

Are you also saying that an end user going from 1.2.3 (i.e. no 4th) to 1.2.4, performing the upgrade, would worth just because there is no 4th value? I will try it as it is definitely worth the try.

I don't think he is saying that. But what you could do is only update your application if its not a revision or a new build. You have four numbers that represent your version builds. If you have version 1.3.4.6
----1 = Major ----
----3 = Minor ----
----4 = Build ----
----6 = Revision ----
And so, if you do a revised edit and edit something, your revision number will increment. You should be in control of your own application updater, and if you can control when your application updates, you can tell it to not upgrade if its only a revision change or a new build. What I am telling you is to check which number has incremented against the current (old application) version. I don't know how your updater works or how you have your setup configured, but if you built a custom updater, like I use, then you'd be better off for managing when your upgrades will proceed or ignore. Telling us more about your update process might help.

 

[GeneralZaphod]

I don't think he is saying that. But what you could do is only update your application if its not a revision or a new build. You have four numbers that represent your version builds. If you have version 1.3.4.6
----1 = Major ----
----3 = Minor ----
----4 = Build ----
----6 = Revision ----
And so, if you do a revised edit and edit something, your revision number will increment. You should be in control of your own application updater, and if you can control when your application updates, you can tell it to not upgrade if its only a revision change or a new build. What I am telling you is to check which number has incremented against the current (old application) version. I don't know how your updater works or how you have your setup configured, but if you built a custom updater, like I use, then you'd be better off for managing when your upgrades will proceed or ignore. Telling us more about your update process might help.

Thanks much for responding. Interestingly I removed the * entirely. It really wasn't achieving any good purpose anyway other than to identify "in-between" builds which aren't a thing with us. The result: SO FAR... cross my fingers, the problem isn't there anymore. I will also add I suspect your proposal might also work, however I also suspect this. The revision number seems to be randomized (like a 16-bit range value it seems). I suspect that when you perform upgrade on a randomized value, it will find the one with the largest revision number and upgrade that. This would explain what I was seeing, but also explain why it doesn't do this anymore. You would think it would be date-based knowing this value is random?

 

[Skydiver]

There are two issues at play in your situation when you were using the wildcard in the version number.

The first problem is that you were always calling Upgrade() whenever the version is different from the previous version. You really should only be upgrading if the current assembly version is greater than the previously saved version.

The second problem is likely that your asterisk was only on the Revision part of the version, rather than the Build. Basically, if you or your other co-workers are working on your private builds across multiple days, the Revision part rolls over. From the documentation, here's the rules of how those parts of the version number are updated:

A version number such as [assembly:AssemblyVersion("1.2.*")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")]specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.

I hope that you actually have a build server, and the build server is the one that creates the official released version that your testers and customers get. If you are giving out release builds from your private development machines, you've got to mature your development process.

I highly recommend the MSBuild Extension Pack, and use its AssemblyInfo task to auto increment the version number on the build server. As for the development machines, you can use the asterisk in the Build field so that both the Build number and Revision fields are relatively unique, but at the same time always increasing.