tags:

views:

521

answers:

2

I've messed up my WiX-based installer on multiple servers so that it no longer removes files or components (or even other features) during an uninstall. The MSI log shows that PreviouslyPinned=1 on all the components that won't uninstall.

I don't have anything fancy going on like using SharedDll count or even shared components among different installers.

I think I've tracked it down to a particular revision of my WiX code. I did a couple of stupid things. I (unintentionally) created an unmanaged component with a blank Guid

<Component Id="file.ext" Guid="">
    <File .../>
<Component>

and I also changed another component's file location and Id (but not it's Guid). All components present in earlier revisions show PreviouslyPinned=1 and won't uninstall, and new components added after this revision install/uninstall correctly.

How can I get my installer back to normal and remove these previously pinned components?

+3  A: 

Windows Installer actually supports the concept of a blank GUID. It means "install, but don't register the component": http://msdn.microsoft.com/en-us/library/aa368007%28VS.85%29.aspx (ComponentId entry explains what happens with a null GUID).

I just tested with WIX and it appear to respect a blank GUID entry (i.e. no guid is auto-generated). Remember the 1:1 rule between absolute path / key path and GUID:

  • If you change the GUID, a new absolute path should be used for the component key path.
  • If you change the absolute path (for example by renaming a file, or moving it), you should change the GUID.

In summary, the GUID reference-counts the component's install key path, not the file - which may move, but then the file has a new identity via a new GUID (think of two files with the same name in different folders - they are different files, different identities).

Cleaning up messed up GUID reference counting can be a bit messy. I find that if I can change the file name that effectively removes the problem. I also generate a new guid and hence break the link to old guid's ref count. You can also rename the installation folder (which would ideally mean that all component GUIDs should be changed as well). The RemoveFile table concept can be used to remove files on install and / or uninstall that have not been registered as components (for example generated files).

Glytzhkof
What I hear you saying is that, since a blank GUID doesn't even register a component, it should have no effect on other components. Is that right?
ranomore
Yes, in general the blank GUID should have no effect on other components since MSI ignores it after installing the file. However, rarely a fact without modifications: the file installed by the blank GUID will not be uninstalled. If this is a versioned file, and you don't change the install location before adding back a guid, it's theoretically possible that the existing file could block the install of the new file version (if the existing file is a higher version). There are also a few other unlikely scenarios if you use minor upgrades, but if you don't use that I won't go into it.
Glytzhkof
Thanks for your detailed answer! In the end to get everything else to unstall properly (removing the PreviouslyPinned=1 references from the MSI log), I had to go into the registry on that PC and remove all components from my installer under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<user-sid>\Components based on a tip I found here http://blogs.msdn.com/icumove/archive/2008/06/17/windows-installer-error-2908-with-sub-errors-1402-and-1450.aspx
ranomore
+1  A: 

Changing the id of the component and using a valid GUID should make things right.

Gabriel
I was hoping by "making things right" you meant allowing all the PreviouslyPinned=1 components to uninstall. That didn't happen when I changed this.
ranomore

related questions