SharedDllRefCount is almost always not required. You need it only if the same files might be installed to the same location at a later date with a non-Windows Installer setup - these typically update SharedDllRefCount for the file path in the registry.
As the MSDN docs say: "If this bit is set, the installer increments the reference count in the shared DLL registry of the component's key file. If this bit is not set, the installer increments the reference count only if the reference count already exists." And as you can see, if you tell Windows that a file is shared with a non-MSI setup, it won't remove it if the decremented count is greater than zero. At the risk of stating the obvious, MSI setups use component guid ref counting, not the shared Dll ref count. Phil W -----Original Message----- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Thursday, August 15, 2013 6:43 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Converting VS Setup project to WiX I am replacing a (very) old Visual Studio installer project with WiX. I've copied the UpgradeCode from the old installer and have remove existing products scheduled after install validate but I am seeing slightly odd behaviour if I upgrade from old to new and subsequently uninstall: some DLLs are not being removed. If I manually uninstall the old version before installing the new one, I don't get this problem. The difference between these DLLs and others which are removed seems to be that the component IDs for those left behind have changed. (OK so, as I *now* understand it, that breaks component rules, however these are shared components which have already been released into the wild in other installers.) A verbose log of the upgrade install shows "SharedDllRefCount=3" for each of the DLLs in question which I guess is why they aren't subsequently removed. So the first question is, why is ref count 3 (given that the previous version has been removed)? Also I had SharedDllRefCount="yes" and, after further testing, it appears that setting it to "no" fixes the problem. The next question, then, is: is that a good idea? would it have other consequences, especially with regard to the other installers already "out there"? Thanks, Kevin ---------------------------------------------------------------------------- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
