13

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!

Matt Bishop
  • 1,487
  • 1
  • 12
  • 19
  • Are you running the Setup.exe file directly or the YourApp.msi? – cmw Jan 15 '10 at 18:28
  • I realize that it doesn't offer the full flexibility of a .msi, but is ClickOnce deployment an option? It'll automatically update without removal and even allow users to roll back to previous version, if necessary (and if you allow it). Also, have you tried different permutations of those options? How about not incrementing the AssemblyVersion? – Jay Jan 15 '10 at 22:31
  • Running either setup.exe or the msi produces the same result. I probably haven't tried every single combination of these options, but I must have tried most of them by now! I've definitely tried leaving AssemblyVersion unchanged - I'm pretty sure AssemblyVersion isn't (supposed to be) important here. – Matt Bishop Jan 16 '10 at 01:34
  • Oh, and ClickOnce isn't an option, alas... – Matt Bishop Jan 16 '10 at 01:43

6 Answers6

19

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.
Community
  • 1
  • 1
Matt Bishop
  • 1,487
  • 1
  • 12
  • 19
  • AssemblyVersion vs AssemblyFileVersion helps me a lot, especially to not place AssemblyFileVersion in AssemblyInfo.cs files! Great help! – psulek Mar 25 '11 at 09:59
  • Agreed with the final point. Do everything as per the question and make sure you remove the AssemblyFileVersion in AssemblyInfo.cs – cmroanirgo Aug 24 '11 at 08:08
  • I have the same problem and I find this solution works-ish. Unfortunately because I store my application data in Application.LocalUserAppDataPath; I cannot change the file version otherwise this points at a new folder \AppData\Local\Company\AppName\V1.0.0.2 etc and all my data is in V1.0.0.0. This would require me to rebuild all the data to the new folder whenever the exe and installer are updated. Any suggestions? – Richard Baxter Mar 13 '12 at 15:40
5

To have it install over the previous version:

  1. Highlight the setup project.
  2. Press the F4 key for properties. (Right Click is a different properties box.)
  3. 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.

JBrooks
  • 9,901
  • 2
  • 28
  • 32
4

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!

Fred
  • 1,292
  • 10
  • 24
  • I'm always incrementing at least the minor version, so I don't think that'll be it. Thanks for the pointer to Advanced Installer, though... – Matt Bishop Jan 16 '10 at 01:39
0

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.

Adi Lester
  • 24,731
  • 12
  • 95
  • 110
Aman
  • 1
0

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

Ed.
  • 1,172
  • 6
  • 9
0

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.

Repeat Spacer
  • 373
  • 3
  • 17