RemovePreviousVersions=True but previous version is not removed from the target machine RRS feed

  • Question

  • My machine originally had Visual Studio 2005 installed.  At that time I created a setup and deployment project.  I made two builds of the project.  One was version 3.25.6 and the other was version 3.25.7.  I installed version 3.25.6 on a clean XP Pro SP2 virtual machine.  Then I installed version 3.25.7.  This resulted in one version of the program on the virtual machine and one entry in Add/Remove programs.  This is what I would expect since RemovePreviousVersions was set to True.

    Now my machine has Visual Studio Team System 2008 Development Edition (version 9.0.21022.8 RTM) installed.  I took the setup and deployment project that was created in VS 2005 and made two builds.  One was version 3.26.0 and the other was version 3.26.1.  I installed version 3.26.0 on a clean XP Pro SP2 virtual machine.  Then I installed version 3.26.1.  This resulted in two versions of the program on the virtual machine and two entries in Add/Remove programs.  One for version 3.26.0 and one for version 3.26.1.  The RemovePreviousVersions property is still set to True.  I opened the two MSI files in Orca.  The ProductCodes are different and the UpgradeCodes are the same.  Why isn't the previous version removed?

    I would appreciate any help you can offer.  If you need any additional information please let me know.

    Thank you -
    Karen Ahmad

    Thursday, March 19, 2009 9:07 PM

All replies

  • Make sure the InstallAllUsers setting (Just me and Everyone) setting is the same. Just me won't upgrade Everyone (and vice versa).
    Phil Wilson
    Friday, March 20, 2009 9:32 PM
  • Thanks for the reply!

    On the Deployment Project Properties page the InstallAllUsers property is set to True.  On the Installation Folder Dialog Properties page the InstallAllUsersVisible property is set to False.  Therefore, the program is always installed for all users.

    I would appreciate any other help you can offer.

    Thank you -
    Karen Ahmad
    Friday, March 20, 2009 9:47 PM
  • The issue isn't that *one* of the setups has InstallAllUsers set True, the requirement is that they are *both* installed with the same value. If the older one was installed for Just me (InstallAllUsers false) then the new one won't upgrade it if it has InstallAllUsers=True.
    The other requirements are that the UpgradeCode guids are the same in both setups, and the Setup Project's Version values >= 1.0 (but you seem to have those already).
    Phil Wilson
    Tuesday, March 24, 2009 5:44 PM
  • Thanks for the reply!

    All of the installations in the original post have InstallAllUsers = True and InstallAllUsersVisible=False.  I believe this means that the installation defaults to "Install for everyone" and that the user is not able to change it.  That would mean that all the installations are installed with the same value.  Please let me know if I am missing something here.

    The setup and deployment project I am building has DetectNewerInstalledVersion=True and RemovePreviousVersions=True.  I started comparing the MSI created by Visual Studio 2005 with the MSI created by Visual Studio 2008.  All of the entries listed below are missing from the MSI created by Visual Studio 2008.

    Upgrade Table
         UpgradeCode = UpgradeCode GUID
         VersionMin =
         VersionMax = ProductVersion
         Attributes = 256

    Upgrade Table
         UpgradeCode = UpgradeCode GUID
         VersionMin = ProductVersion
         Attributes = 258
         ActionProperty = NEWERPRODUCTFOUND

    CustomAction Table
         Type = 19
         Target = [VSDVERSIONMSG]

    InstallExecuteSequence Table
         Condition = NEWERPRODUCTFOUND AND NOT Installed
         Sequence = 201

    Property Table
         Property = SecureCustomProperties

    I manually added all of these entries to the two MSI files created by Visual Studio 2008.  I also changed the sequence of RemoveExistingProducts in the InstallExecuteSequence table from 6550 to 1525 (after InstallExecute to after InstallInitialize).  After I made these modifications I installed v3.26.0 on a virtual machine and then installed v3.26.1.  This resulted in one version of the program on the virtual machine and one entry in Add/Remove programs which is exactly what I want.

    Why are these entries missing from MSI's that are built with Visual Studio 2008?  Also, is it possible to write code to add/modify these entries and run it as a PostBuildEvent?  If so how would I do that?

    Thank You -
    Karen Ahmad
    Tuesday, March 24, 2009 7:51 PM
  • I am having a similar problem with the uninstall not occurring first (sometimes).
    I have a rather simple installer that I made with visual studio 2008 that installs a couple EXEs and a DLL along with some other files into a directory. 

    I have RemovePreviousVersions set to TRUE and InstallAllUsers set to TRUE.

    When I need to do a new release, I update the Version field with a new version number in the installer and VS prompts me to update the product code, to which I answer YES.  I have verified that it does indeed change the product code, but the package code also gets changed with it (verified by diffing project files using sourcesafe).

    The UpgradeCode never changes between versions.

    My version number changes are of the form:  "1.1.2"  -> "1.1.3" for example (just in case that has anything to do with it).

    So only 3 fields are different between builds:  ProductCode, PackageCode, and ProductVersion. 

    When I've done all that, I build the installer.
    When I install the new version (I always install for all users and always into the same directory), I have seen three different results at various times:

    1. It will appear to in install the new version, but I really end up with the old files still there (and one instance in the add/remove programs).
    2. I end up with 2 instances of the app in the add/remove programs, both with the same name, and both pointing to the same directory.
    3. It will uninstall the old one first and then install the new one (what it is supposed to do).

    It is very frustrating to explain to users that to be safe, they have to uninstall the old manually before installing a new release because I have to tell them "it doesn't always uninstall the old one like it is supposed to".  

    Any suggestions?  Why isn't this working?  What am I missing here?

    Visual C++ Developer
    Thursday, June 11, 2009 4:59 PM
  • There are some general rules about upgrades and some specific to Visual Studio versions
    1. Old and new products must have identical UpgradeCode values and different ProductCode values.
    2. Old and new products must have identical values for InstallAllUsers.
    3. New product's setup Version (the setup project, nothing to do with file versions) must be higher.
    4. All setup versions (again, not file versions) must be 1.0 or greater.
    5. Visual Studio 2008 RemovePreviousVersions is not the same as 2005 and uses file update rules. Therefore if you want to update files you must increase file versions. This is normal practice in all setups, patches etc that file versions are updated if they have new content.
    6. Visual Studio 2005 RemovePreviousVersions behaves like an uninstall of the older one followed by an install of the new one, and rules 1-4 still need following, but you could get away with not incrementing changed file versions because of the "uninstall then install" nature of the upgrade.

    Phil Wilson
    Thursday, June 11, 2009 6:01 PM
  • Thanks for the response.

    I was familiar with 1-4, but 5 and 6 I did not know about.    We used to use 2005, but now we use 2008, so perhaps that explains why I saw the uninstall/install behavior before.  

    So you're saying that only individual files whose 'file version' is different would be "uninstalled" (replaced maybe is the better word) when I do an installation over the top of an older version of the same thing. And it is a file-by-file decision made by the installer.  Is that right?

    I'm assuming when you say "setup version" you're referring to the "Version" field in the installer deployment project properties window of the installer project.  I do increment that (e.g. my latest build went from 1.1.8 to 1.1.9).  

    I'm not sure what exactly you mean by file versions, though.  Only applications seem to have file versions (as set in the Version field in the resource file and seen by right clicking an EXE file and viewing the version tab).  Things like DLLs and text files don't seem to have this information, so I don't think I know what a 'file version' is.  Could you explain?



    Visual C++ Developer
    Friday, June 12, 2009 5:51 PM
  • Yes, Visual Studio 2008 upgrades (RemovePreviousVersions) use file replacement rules, and yes it is a file by file decision made by the installer. Yes, the setup project version is the Version in the deployment project's properties window.

    All binaries have versions, and that includes exe and Dll files. If your Dlls don't have a version then they should have. If you have an interop Dll generated by adding a refernce to a COM typelibrary then it may not have a version, but I believe that if you manually use tlbimp on the COM object and use the /asmversion switch the assembly version might flow into a file version.

    Data files don't have versions, correct, and data files don't get replaced if they have been updated. So if you install a database and then use RemovePreviousVersions it will not replace the installed database if it has been updated. Internally, when a data file is installed its modify and creation dates are made identical.  If the data file gets changed then these dates change, and the file update rules say that this file will not be replaced. My guess is that this was part of why the update method changed in VS 2008. In a VS 2005 setup you could install a database, update it for weeks, do a RemovePreviousVersions upgrade and the DB gets removed.
    Phil Wilson
    Friday, June 12, 2009 6:57 PM
  • I was having some of the same issues as JD Farndon noted:

    1. It will appear to in install the new version, but I really end up with the old files still there (and one instance in the add/remove programs).
    2. I end up with 2 instances of the app in the add/remove programs, both with the same name, and both pointing to the same directory.

    After reading everyone's dialog, I figured out what I was doing wrong.  I did have all of the proper settings in my Setup and Deployment package.  However, I neglected to make any changes in the Assembly Information of my start up project.  Once I went back in and incremented the File Version and Assembly Version numbers, when I rebuilt my solution, all of my files had new version numbers associated  with them.  When I installed the package, this time it uninstalled everything from the previous version and installed the newest versions of all my files - which is just what I wanted.

    I want to thank all of you for your information, which pointed me in the right direction.


    • Proposed as answer by Richie916 Wednesday, May 30, 2012 7:04 PM
    Wednesday, July 8, 2009 4:21 PM
  • Hi All,

    I am new here and its pretty old thread I might be bumping an old thread but I didnt find that I can best describe my problem somewhere else. I have exactly the same problem I understand the above replies to change product code nd file version but what if I have used some other third party dll's how I am going to increase their version no. also I have so many resource file and other files which do not have versions and not at all related to my primary exe so after increasing the version of my exe their version also dont get increased

    So how should I uninstall the previous version in my scenario

    Wednesday, January 27, 2010 5:40 AM
  • Make sure the InstallAllUsers setting (Just me and Everyone) setting is the same. Just me won't upgrade Everyone (and vice versa).
    Phil Wilson

    I am facing this problem.

    It is too much to require users to remember which setting they use when they installed my version 1 a couple of years ago.

    How do people get around this problem?  I am certain some software are able to replace earlier versions even if users have the choice to select Just me or Everyone.

    Monday, February 15, 2010 3:24 AM
  • Saurabh, I think you are confused over what the version numbers refer to.

    If the existing software was installed from a Setup & Deployment project with ProductCode X and Version Y, your new MSI won't install if it was created from a Setup & Deployment project with the same ProductCode and Version.  This version number is refering to the Version property of the Setup & Deployment project, not the assembly or product version of your software.

    Monday, February 15, 2010 3:49 AM
  • To clarify things, you need to change two lines in AssemblyInfo.cs of each project:

    [assembly: AssemblyVersion("")]

    [assembly: AssemblyFileVersion("")]

    If you change the AssemblyVersion only, upgrading installs don't replace files with newer versions.  File version must be changed, too.


    • Proposed as answer by OliverWAusS Tuesday, February 28, 2012 11:45 PM
    Monday, March 29, 2010 5:59 AM
  • Most setups define a rule, and usually that is that the install must be Everyone, and enforce it with a Privileged check in LaunchConditions.  Windows Installer doesn't allow cross-context upgrades, but a custom bootstrapper can detect the situation and manualy uninstall the old one first, but that isn't the same behavior as an upgrade.
    Phil Wilson
    Monday, March 29, 2010 6:04 PM
  • I ran into the same issue of having two instances of my application in the Add/Remove Programs.  I verified that the upgrade codes are the same, the product codes are different, the install for all users is the same, and my version numbers are different between the two installers.

    I originally had RemovePreviousVersions set to false, after changing it to true I no longer had two instances of the application in the Add/Remove programs.  However, the issue that I now have is when I run a newer installer it deletes configuration files from the older version.  This is something I would like to avoid.

    Thursday, April 22, 2010 8:28 PM
  • Oh man !! I am beginning to hate myself for picking Visual Studio to create my setup project.

    Phil, I read your web page and many other places, it clearly states that when you initiate an update the first operation is "Uninstall of the old build" which is the followed by the  "installation of the new build".

    For some strange reason, its happening the other way around for me. At the end of it, I do see one entry in the Add/Remove programs, which is good. But the sequence is just crazy.

    The installation seems to work fine. All my files are perfect (they are all installed as per the new installer). Everything I wanted the new installer to do is done (including the custom action). But things go wrong after this, the uninstallation of the old version is now triggered. I really don't understand how the uninstall is working here. My new files are not removed. But the custom action for uninstall in my earlier version is invoked which completely messes up my installation.

    In both the projects, the DetectNewerInstalledVersion is set to "True", the InstallAllUsers is set to "True", the RemovePreviousVersion is also set to True. The installation in both the builds are for All Users as I have disabled that option in the UI as well.

    My version numbers are 5.0.0 and 5.0.1

    The Product codes are different and the Upgrade codes are the same. I have always used VS 2008.

    Can anyone help me out with this ?

    Wednesday, April 28, 2010 8:36 PM
  • I hit this exact problem, and it's because vdproj seems to put the RemoveExistingProducts action way late in the InstallExecuteSequence table in the MSI.  As a late breaking hack I used the following vbs script to hit it with a big hammer:

    Dim installer, database, view, result
    Set installer = CreateObject("WindowsInstaller.Installer")
    Set database = installer.OpenDatabase ("DataServerInstaller.msi", 1)
    Set view = database.OpenView ("UPDATE InstallExecuteSequence SET Sequence=1450 WHERE Action='RemoveExistingProducts'")
    Set database = nothing

    In all of MSI's I've worked with, vdproj sets InstallValidate to 1400 and InstallInitialize to 1500, so 1450 is a good Sequence value.  Look inside your msi's with orca to verify before running this.

    If you can, run run away from vdproj.  It's a horrible mess.  Use WIX if at all possible next time around, and start EARLY in your development process.  It'll take you a little while to get comfortable with it, especially since the tutorials are focused around commandline usage of the tools as opposed to wixproj, but you'll own it instead of it owning you.

    • Proposed as answer by vijaygos Tuesday, August 3, 2010 3:24 AM
    Thursday, June 17, 2010 1:48 AM
  • Here's what I found out while having the same "upgrades don't work" problem.
    Search your help index for UpgradeCode property.
    You'll find that the UpgradeCode must remain the same as the first version you deployed.
    Otherwise the installer doesn't know what to uninstall.
    I'm currently having the same issue and am searching for the previous UpgradeCode so I can insert it back into my revised MSI.


    "A cluttered desk is a sign of a briliant mind", unless you can't spell brilliant, which means your just a slob.
    Friday, June 18, 2010 10:52 PM
  • I was able to upgrade my .vb page files, but the app.config does not update to the new version.  Did anyone have this problem?
    Friday, July 16, 2010 1:28 PM
    • Proposed as answer by tstuetzer Wednesday, June 8, 2011 2:52 PM
    Monday, October 11, 2010 11:37 AM
  • How could you solve cant work...
    Wednesday, June 8, 2011 2:52 PM
  • Thank you for this, setting the sequence to 1450 works perfectly!
    Monday, May 21, 2012 12:30 PM
  • Thanks, this fixed my Problem.

    Old version was user only, new version is all users - very strange behavior.

    So i or my customer have to manually deinstall all old versions and than install the new version. wtf?

    Friday, January 16, 2015 9:34 AM
  • A Windows Installer upgrade will not upgrade from per user to per system or vice versa, that's just the way it works.

    Phil Wilson

    Friday, January 16, 2015 5:49 PM
  • If anyone is searching for this and using Visual Studio 2015 with the Microsoft Visual Studio 2015 Installer Projects extension (found here:

    Kimmo K's solution was the last key that I needed for this issue. Here's what you need to have in order for your installer project to correctly install over the previous version (no extra entries in the Add/Remove Programs) and replace the old installed files with the new ones (changes):

    For the first installation of your product:

    - Take note of the Upgrade and Product Codes in the installer project's properties. The Upgrade Code should stay the same no matter what.
    - Set the version number in the installer project's properties (i.e. 0.1.0 - does not need to be > 1.0.0).
    - Not sure if these have to be this way, but here are the settings for previous versions:
      - DetectNewerInstalledVersions - True
      - InstallAllUsers - True
      - RemovePreviousVersions - True
    - Set the assembly version and the file version as Kimmo K mentioned above. Open your AssemblyInfo.cs and look for these settings:
      - [assembly: AssemblyVersion("")]
      - [assembly: AssemblyFileVersion("")]

    Install your product. Now, make these changes in order for new updates to show (add a control like a Button to your form so you can see the change):

    - Increment the version number of the installer project (i.e. 0.1.1). When it asks to change the product code, click YES.
    - Increment the assembly version number and the file version number (just like in the last step above - i.e.

    Install your product again. You will not get a dialog telling you that the product is uninstalling, instead it will proceed with a normal installation as if it was the first time. However, it will install over the previous version, and will also contain all of your new files/updates.

    Hope this helps!

    • Edited by Riccaforte Tuesday, December 1, 2015 7:31 PM
    Tuesday, December 1, 2015 7:29 PM

  • 5. Visual Studio 2008 RemovePreviousVersions is not the same as 2005 and uses file update rules. Therefore if you want to update files you must increase file versions. This is normal practice in all setups, patches etc that file versions are updated if they have new content.

    Phil Wilson

    Thanks a lot! :) 

    I finally solve my fail :D

    I'm always change version Setup project before build but I'm never change my application version. 

    So, Setup is install but application files never change. :D 

    This very old post but I saw my mistake. :D 


    Sunday, August 27, 2017 4:57 PM