Click here to Skip to main content
15,867,308 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi, please excuse me for working with an old version of Visual Studio, but I have inherited a VB .NET 2005 project, and needed to make some mods and produce some form of distribution files for our users. I am an old VB6 programmer, and I've gone through a ton of learning (using codeproject examples - THANKS GUYS!) to get to the point where the project builds and runs in the IDE.

Now it is time to deploy, and despite setting the Assembly Information properties to Assembly Version 2.0.0.* and File Version 2.0.0.0, the installed version continues to show up in 'Programs and Features' (formerly Add/Remove Programs) as Version 1.5.2, and the application will not replace an old version, so I have to manually remove it (which was how I noted the version issue). I have searched all my solution files for any occurrence of '1.5.2', and none exist. I've tried opening every source file and making/deleting a single change to force them to recompile, and still no happiness. I do not have the time or energy to try importing the project into a newer (2008 or 2010) version of VS, so I'm hoping someone here can point me toward a fix, which I've tried all day to figure out what to search on in Google.

Thanks, any help greatly appreciated.

Kindest Regards!

John
Posted
Updated 22-Jul-14 16:34pm
v2
Comments
dalkeeper 22-Jul-14 23:53pm    
Hi, Sergey,

In the file AssemblyInfo.vb I had the lines:
[assembly: assemblyversionattribute("2.0.0.*")]
[assembly: assemblyfileversionattribute("2.0.0.0")]

which had to have been put there by the properties settings, but no AssemblyInformationalVersion. So I added that and now have:

[assembly: assemblyversionattribute("2.0.0.0")]
[assembly: assemblyfileversionattribute("2.0.0.0")]
[assembly: assemblyinformationalversion("2.0.0.0")]

But, no joy. Still, the installer fails to remove the previous version (not very gracefully or informatively either), and the uninstaller still shows version 1.5.2. I cannot understand where it would get that version since I can't find it with "find in files".
Sergey Alexandrovich Kryukov 23-Jul-14 1:04am    
Version of the installer is a different thing (unfortunately). You can remove it with one of the RegistryCleaners.
—SA
dalkeeper 23-Jul-14 8:34am    
Here's an interesting thing - I brought the application.msi file into a hex editor and found the string "1.5.2ProductVersion" in there just after the product code.

VSDAllowLaterFrameworkVersionsVSDNETCFGVsdLaunchConditionsVSDCA_VsdLaunchConditionsNOT InstalledxxxxxxProductNameProductCode{xxxxxxxxxxxxxxxxxxxxxxxxxxxx}1.5.2ProductVersioncompany nameManufacturerARPCONTACT1033ProductLanguagePREVIOUSVERSIONSINSTALLEDSecureCustomPropertiesNEWERPRODUCTFOUNDPREVIOUSVERSIONSINSTALLED;NEWERPRODUCTFOUND[VSDVERSIONMSG]ERRCA_CANCELNEWERVERSIONNEWERPRODUCTFOUND AND NOT Installed[VSDUIANDADVERTISED]ERRCA_UIANDADVERTISEDProductState=

Does this shed any light on the cause?
dalkeeper 23-Jul-14 9:00am    
Brute force applied - I manually changed that embedded version in the application.msi file to 2.0.0, and the installer ran giving me the options to Repair or Replace the application. I chose Repair, and it appeared to perform an install, but the version showing in "Programs and Features" still shows 1.5.2. I ran it again, and selected Remove, then ran again, and it upgraded the product code.
dalkeeper 23-Jul-14 9:23am    
Think I found the culprit. There was a folder in my solution working folder called Install, which contained a 'applicationnameinstall.vbproj'. Even though I would have expected that the 'Find in Files' feature would have found this, it had the 1.5.2 string in it. I think this may have been created when I was trying to figure out what the 'Click Once' installation option was all about, but in any case, deleting it and the other 2 files in this folder (autorun.inf and WiRunSQL.vbs) allowed me to rebuild an application.msi with the correct version in it.

Dreadful. This is not a problem at all. The assembly version, file version, and — bonus! — product version are defined by appropriate attributes with the target System.AttributeTargets.Assembly, and nothing else. For example:
C#
[assembly: AssemblyVersion("20.0.0.0")]
[assembly: AssemblyFileVersion("20.0.0.0")]
[assembly: AssemblyInformationalVersion("1.1.0.0")] // shown as "product version"

All your sad history of all your legacy is irrelevant. If you project compiles any file(s) with these three lines, your assembly will be compiled into a module with the assembly manifest having the said version. Normally, in modern versions of Visual Studio, these lines are put in the file"/Properties/AssemblyInfo.cs", but it has no special meaning at all. Only the application of these three attributes is important.

Also, "*" means that some components of the version are auto-generated by the build, but I would use it only during development; the final product release build (I hope you are going to create a command-line build script/batch, otherwise it's not a real development cycle :-)) should put some concrete fixed version values.

You got the exact recipe. Good luck.

[EDIT]

Another bonus advice.

Migrate your project to the .NET version supported by Visual Studio you have. Usually, this is not a problem at all.

No need to apologize for using .NET v.2.0 — it was quite a decent version, with generics and anonymous methods. Using it was never anything wrong. But with later versions, you will have such an important features as lambda expression and type inference, both extremely convenient things, as more.

—SA
 
Share this answer
 
v3
There was a folder in my solution working folder called Install, which contained a file called 'ApplicationNameinstall.vbproj'. Even though the 'Find in Files' feature of Visual Studio did not find the old version string in it, viewing it with a hex editor showed that in fact, it was there.

I think this file was created by previously running the 'Click Once' installation option. Deleting this and the other 2 files in this folder (autorun.inf and WiRunSQL.vbs) allowed me to rebuild an application.msi with the correct version in it.
 
Share this answer
 
I will take a guess

The old version of MSI installer (created with WiX 3.5) had a bug and would not update the version number which was used in VS2005.

Probably see if John's fix above works

Read the old article fix here
http://stackoverflow.com/questions/114165/how-to-implement-wix-installer-upgrade[^]

Other than that but a little more dangerous is to go after the registry entry manually
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
 
Share this answer
 
v3
Comments
dalkeeper 23-Jul-14 9:08am    
Thanks for the input but I don't understand how or where to apply this in my solution. The thread at the link seems to apply to the Wix 'control language' and doesn't look anything like the format of assemblyinfo.vb. Is there somewhere else in my VB solution that I need to look?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900