1

When I try to do an upgrade of my project, I get the following logs for about eight or so components:

MSI (c) (24:EC) [11:50:17:422]: Disallowing installation of component: {290E89A8-6BA7-59F2-B350-BE657C2823BC} since the same component with higher versioned keyfile exists

The uninstall portion of the upgrade seems to remove all of the previously installed files, but when it installs the new files during the upgrade, it seems to disallow the installation of eight or so components/files. The upgrade succeeds, but the these eight files are not present. I use the following criteria for my upgrade (my Product ID is *, by the way):

<Upgrade Id="{16B40AC6-1F80-47CD-9955-BDCC5BB297E4}">
    <UpgradeVersion Minimum="$(var.InstallerVersion)" Property="NEWPRODUCTFOUND" OnlyDetect="yes" IncludeMinimum="no" Language="1033" />
    <UpgradeVersion Minimum="0.0.0" Maximum="$(var.InstallerVersion)" Property="OLDPRODUCTFOUND" OnlyDetect="no" IncludeMinimum="yes" IncludeMaximum="yes" Language="1033" />
</Upgrade>
<InstallExecuteSequence>
...
    <RemoveExistingProducts Before="InstallInitialize" />
...
</InstallExecuteSequence>

I have tried to circumvent the issue using the steps described here but have had no success. Could anyone shed some light as to how I may be able to get my new files installed on an upgrade? What is odd, is that if I do an uninstall of the old version through Programs and Features, and then install the new version, it works and all files are installed (hence, it works when not upgrading), but when upgrading, it does not install some of my files.

Edit: It just so happens that setting the REINSTALLMODE property to amus will force it to reinstall files regardless of version and checksum, and it works now since the default for it is omus, but I am not sure if this is the best approach:

<Property Id="REINSTALLMODE" Value="amus" />
Community
  • 1
  • 1
Alexandru
  • 12,264
  • 17
  • 113
  • 208

1 Answers1

4

The issue seems to be a recurring one, similar to this:

http://support.microsoft.com/kb/905238

Windows decides not to install the files because a higher version exists, but doesn't re-evaluate that decision when it turns out we're doing a major upgrade. I thought this issue had been fixed in MSI 4.5.

Doing the RemoveExistingProducts before CostInitialize should solve the problem, but you'll get some ICE errors and lose migration of features during the upgrade, if you're using that capability.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • The thing is that, as the only installer developer on my team, I can't ensure that people are going to version their files correctly, I guess my only resort is to use "amus" and just install what is packaged with my installer, unless there is a better way you know of? – Alexandru Feb 03 '15 at 18:06
  • What's wrong with REP before Costinitialize? That's a complete uninstall of the old, then the new one is installed, and it fixes your "disallowed" issue. – PhilDW Feb 03 '15 at 18:13
  • I still have to try it, but what's wrong with "amus"? It would just install, all or nothing...I suppose that with CostInitialize, consider this scenario: my team members redesign a DLL file under some new framework, but have not set a version for it. On upgrade, it would not install it if the DLL exists. I guess what I'm trying to say is, I'm trying to avoid bugs coming to me for issues that aren't my own. What I do when I create the installer package is build all dependency projects beforehand, and continue if none fail. That ensures they are the latest version regardless of version numbers. – Alexandru Feb 03 '15 at 18:24
  • 2
    amus is dangerous. Let's say there are some newer versions of files on the system that have security fixes applied, or are just newer versions installed by patches between the original release and the upgrade (hotfixes, 3rd party Dlls in merge modules etc). You'll wipe out of all of those updates with your older versions. BTW if your developers have no discipline regarding file versioning then you are in deep doodoo. Every update, patch, hotfix etc depends on consistent version management of files. – PhilDW Feb 03 '15 at 18:32
  • With RemoveExistingProducts before CostInitialize, I still see "Disallowing installation of component" errors in my installation logs, yet the component did install successfully. How can I now determine when these are valid errors, or when files with older version numbers were not installed? Now it just always seems to install these files... – Alexandru Feb 03 '15 at 19:16
  • I guess there's no good way. If I ever see the errors, I have to figure out what file corresponds to that component and also if that file didn't get installed because of a newer version of the file already present. In any case, I will take your advice and monitor that developers are correctly versioning each file that gets packaged in my installer. – Alexandru Feb 03 '15 at 20:39
  • 1
    You may find that a repair will install the missing files - that seems to be the way of this particular issue. – PhilDW Feb 04 '15 at 18:33