Here’s another issue that had me stretching the limits of my google-fu:
Scenario:
- Plugin being installed using WIX-generated merge module and installer
- Merge module has components that are potentially shared between several other plugins
- Each component is flagged as < … Shared=”yes” SharedDllRefCount=”yes”> in the merge module WXS file.
- At some point in testing, the installer has failed on a particular machine.
- When the plugin is uninstalled on that test machine, the shared components are not removed even if there is nothing still referencing them.
To help debug this, I ran a manual uinstall, using msiexec, with verbose logging enabled:
msiexec /x myInstaller.msi /lv c:\uninstall.log
After much wading through the printout, the following line caught my eye:
MSI (s) (BC:B8) [09:41:31:294]: Executing op: UnregisterSharedComponentProvider(Component={F84EDDFB-2E5F-401B-9649-7B7F9CC32AD6},ProductCode={CCD6CBDA-859B-4846-88CC-24F7D64A4BCA})
MSI (s) (BC:B8) [09:41:31:294]: Executing op: ComponentUnregister(ComponentId={F84EDDFB-2E5F-401B-9649-7B7F9CC32AD6},,BinaryType=1,PreviouslyPinned=1)
Specifically, the “PreviouslyPinned” count. This indicates that Windows believes something else is referencing this component.
This led me to the crucial bits of information I was lacking: (a) remembering that at some point the installer had failed, which hinted at that fact that something hadn’t been cleaned up properly, and (b) identifying how Windows keeps a track of the shared components. The latter part was obviously registry related, which led me to the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
The solution was to manually delete all the relevent shared componenent entries (which are helpfully sorted by location) in that registry key. Once done, the install/uninstall cycle worked as expected.
