I have a VS2008 setup project, which creates a setup.msi which installs a WinForms application (C#).
Every time I update the version number, the users first have to uninstall the previous version before they can install the new one. Otherwise we get the dreaded "Another version of this product is already installed" message.
This is what I'm doing already when I build a new version of the installer:
- Set RemovePreviousVersions=true and DetectNewerInstalledVersion=true
- Increment AssemblyVersion (of the exe that's being deployed)
- Increment Version (of the setup project)
- Generate a new ProductCode (as prompted by VS, when the Version is changed)
- Leave UpgradeCode unchanged
And yet it still refuses to uninstall the previous version. So, what have I missed? Or what am I doing wrong?
Thanks!
Semi-answering my own question, just for the benefit of anyone who's interested:
Firstly, I found an incredibly useful article on how MSI updates work.
Secondly, I found InstEd, a rather nice freeware MSI editor, which showed me that there was nothing obviously wrong with my MSI file. (Yes, I could use Orca instead, if I didn't mind downloading the whole Windows SDK to get it.)
Thirdly, and annoyingly, the original problem seems to have fixed itself and I can't reproduce it any more. If it comes back, and if I fix it again, I'll add a comment here!
Anyway, all this brought up a new - arguably worse - problem: the MSI now claimed to update the application but didn't actually install anything! The solution to that is as follows:
- AssemblyVersion doesn't matter, but
AssemblyFileVersion absolutely
does: it must increment, if you want the new files to be installed. (This is a change in VS2008, compared to VS2005. See, for instance, this
discussion on the Microsoft
groups.)
- However, AssemblyFileVersion can't autoincrement the way AssemblyVersion
can. Setting it to 1.9.* (or
whatever) will just result in an
error. The solution, from Stack
Overflow this time, is to set
AssemblyVersion to autoincrement, and
then open AssemblyInfo.cs and remove
the AssemblyFileVersion attribute
altogether. This will force the file
version to equal the assembly
version.
To have it install over the previous version:
- Highlight the setup project.
- Press the F4 key for properties. (Right Click is a different properties box.)
- Change Version. Say yes to the prompt asking to change the product code.
Keep in mind, even if you rebuild the solution it doesn't rebuild the setup project. You need to rebuild the setup project as a separate step.
Second, you don't need to Increment AssemblyVersion every time. Set it to something like 2.1.* and it will do it automatically.
I am not 100% familiar with VS 2008 setup projects (I use Advanced Installer myself- HIGHLY recommend it BTW; they even have a freeware version!), but I have run into this before and it's not documented very clearly.
There are 4 parts to the version number- as you are well aware I'm sure: Major.Minor.Build.Revision. The REVISION is NOT checked by windows installer. If all you're doing is incrementing the revision, it won't work. You have to increment at least the build of the ProductVersion value.
Hope that helps!
The Installer service is making decisions based on the contents of the Upgrade Table, so that's where I would look. Does the table have an entry for your upgrade code, does the product version of the currently installed version fall within the range of versions specified for upgrades, do the attributes look ok (for instance, is the msidbUpgradeAttributesOnlyDetect
attribute not set), and so on.
MSDN describes it all here - http://msdn.microsoft.com/en-us/library/aa372379%28VS.85%29.aspx
Don't forget to increment the assemblyFileVersion! If you don't specify the assembly file version then the compiler assumes it to be the same as assemblyVersion. However, if assemblyFileVersion is specified then it must be incremented.
I came here to get help to same problem. After reading linked incredible useful article I suppose my problem was, that I had installed previous version with "Just me" option and the new installer had InstallAllUsers property selected (in Visual Studio project properties). So after uninstalling previous installation from control panel the update now works. Maybe this helps someone.