Remove a GUID="" component installed with WiX

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 track开发者_运维问答ed 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?

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(VS.85).aspx (ComponentId entry explains what happens with a null GUID).

I just tested with WIX and it appears 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).

UPDATE (Aug, 2018): Just want to add that you should be careful renaming your dlls or exe files if your application relies on LoadLibrary / LoadLibraryEx or whatever similar constructs that "hard code" file names - that are to be loaded - deep in the source code.

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

The short answer is:

Yes, using MSI components without GUIDs is kind of a batch copy method. Copy and forget. Of course you have to add one single thing: Removing all files before every overinstall or uninstall(condition "REINSTALL or PATCH or REMOVE") or Major Upgrade. Without that, it does not really make sense. You can do that in a custom action, even with CMD.exe /c RD /S /Q .... (Of course, custom code is more elegant than this)

If you do it right, you can manage to have quite simple setups without all the traps, MSI normally have. Of course it is easier, if you remove recursively a whole directory that file-by-file.

Have not tried yet, but I will: Having "dynamic" components without GUID and normal components and then providing a patch. Theoretically this should work and this would be a good workaround for a number of patching problems resulting of highly changing file sets between patches.

1. In fact, components without GUIDs are the real "dynamic-file-linking" method often wrongly acclaimed by several tools or persons.

Other "ways": 2. Generating GUIDs automatically is just an automation step (but of course part of every good setup build infrastructure :-) In my eyes this is not dynamically, because if you make it dynamically, you do it wrong:

2a. Generating GUIDs which are completely random each time => wrong algorithm

2b. Generating GUIDs only the first time a component is created and having implemented intelligent "diff" recognition for new resources to be packed in a new component => The only working file-tree-sync method. But you can do much wrong here... It's for experts.