Uninstalling a Previous Version from an MSI
Like a lot of other developers, I use the Setup & Deployment Projects in Visual Studio 2005 to create MSI files for software installs. Typically, this is a Windows Forms based application. For our in house users, especially those testing new software, there could be many iterations of a piece of software. Of course, this means installing the updated version every time I make a correction or add a new feature. Unfortunately, this has also always meant uninstalling the previous version using the trusty old “Add/Remove Programs” option in the Control Panel. Needless to say, this tends to grate on the users nerves after the first 20 reinstalls.
So, you might be wondering why I did not simply use the RemovePreviousVersions Property of the Deployment Project. The problem was that it never worked. I would set that property to TRUE and still the installer would not proceed until the previous version was uninstalled. While I found this truly annoying, it was never a big enough deal to spend a lot of time trying to figure out why the property was not working as expected… until now…
Have you ever ignored a problem until one day you just say “darn it – I’m going to figure this out no matter what it takes!”? Well, for whatever reason that was my attitude this morning. And fortunately for me, it didn’t take too long to figure out. The key is in the property name itself: RemovePreviousVersions. It is the Version part that somehow managed to elude me all this time, and therein lies the secret: I was never changing the version number. I had always focused on the Previous part before, assuming some kind of temporal meaning, incorrectly assuming that Previous meant Prior. Sometimes, our own brains just get in the way.
Of course, once I read it properly, the solution presented itself: I needed to change the Version number. I think part of my mental block here is that Versioning never occurred to me. If I remember correctly, in Visual Studio 2003, you specified a wild card and versioning happened automatically. That doesn’t appear to be the case now: I’m not saying it isn’t, but I am saying that I’m not going to take the time to investigate it. What I am going to do, from now on, is increment the Version property of the Deployment Project whenever I am preparing to deploy the Installer.
I’m going to chalk this one up as a Homer Simpson “DOH!” [slaps forehead], but hey, we all have them! Maybe this one can help someone else get over the same hurdle.
I am not able to find the version property of my deployment project. I am VS2008 and this is a VC++ COM office add in.
Inside the Solution Explorer, click on your Setup project and look at the bottom of the properties window. 🙂
Hey, thanks to the Author, this helped me.
Sounds quite simple, but I can’t make it work in my project. We are still in Beta. Thus the version is 0.8, 0.9, etc, etc. I set RemovePreviousVersions to True, increase the version number and change the ProductCode. The MSI still just installs itself and leaves two entries in Uninstall list.
Use InstEd to check the MSI. In Upgrade table, I have one record:
UpgradeCode: UpgradeGUID
VersionMin: 1.0.0.0
VersionMax: 0.8.46 (My current version)
…
ActionProperty: PREVIOUSVERSIONSINSTALLED
Does VS2005 always start from 1.0.0.0? I can modify VersionMin to something like 0.8.0. It looks like the old version is uninstalled when I install the new one, but when I launch the exe the first time, I got “Please wait while Windows configures “. What’s the issue here? A supposed simple task turns out nasty. (sigh)
I think you may need at least version 1.0. You might want to change your numbering scheme, like “1.0.8.46” and then when you get to GA, the release number will be whatever it is. You are still in Version 1, Revision 0, you just have different build numbers.
I’ve never had a problem with using this approach, and I’ve never seen the “Please wait while Windows configures” message. Is there anything in your software that might be configuring the first time it executes?
Joel,
Thanks for the reply. Guess the 1.0.0.0 is coming from VS2005. I’ll have to use something like 1.0.8.46
Even after I use 1.x.x version, the auto uninstall still gives me ‘Please wait while Windows configures ‘ in Vista. I don’t see it during a regular installation. We have 3 custom actions, to create desktop and quick launch link, to auto launch the product after installation and to auto kill the product during uninstall. Guess they must get in the way. I’ll google more.
It was exactly the same with me – I couldn’t be bothered to find out how either – until today! – And you have sussed it out for me – many thanks!
Joel,
Thanks for kicking me in the head over the version number thing with msi files uninstall/reinstall.
so GD simple
dc
From what I read at http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/, the previous version will be removed only if if the previous version and the current user has the same value for INSTALLALLUSERS.
How do I overcome this? It is too much asking people to remember whether they installed Just me or Everyone on something they did a couple of years ago.
Thanks
Cool solution!!!
Worked like a charm… 🙂
thanks a lot, it was a small issue but very hard to find
Great thanks for saving me loads of time!
Hi, i have the version problem.
I changed the version number and then set DetectNewerinstalledversion to true, RemovePreviousVersion to true. After i changed my apln but i didn’t get the updated version. Older version exist message don’t appear.How can i solve this problem.
Regards, aneesh
I changed the version number,Product code,upgrade code and then set DetectNewerinstalledversion to true, RemovePreviousVersion to true.
but iam getting error,
“error 1001.This service already exists” .
How can i solve this problem.
please solve this problem
Don’t change the Upgrade code … that’s supposed to stay the same so Windows knows it’s dealing with the same product.
Sometimes you may have to change the PackageCode also … open *.msi in Orca, click ‘View’ on file menu and then ‘Summary Information’ and use guidgen.exe to create new guid for packagecode.
looks like you may have to write a custom action *.exe to stop a service that your app probably is installing, then remove it before attempting to install the newer version of your app
I tried all of the above. No joy… The installation “runs” but doesn’t overwrite / replace the old files. Any other thoughts?
Saved my bacon; Visual Studio 2010 prompts you to also change the “ProductCode” automatically if you start by changing the Version. Clearly the right way to go.
You are a LIFE SAVER! This has been driving me crazy for YEARS. But like you said, it was one of those things that important to solve until now. Thanks for posting this.
I had a similar problem but updating the version in the setup project was not sufficient. I found that I had to update the FILEVERSION in my app.rc resource file in my main application project, otherwise my exe would never get updated to the latest version.