Windows Installer does not count references, strictly. It notes in the registry which products have installed a component, and where the key path of the component was installed to. It adds one reference for each product that installs the component.
When you uninstall a product, or remove a feature from a product, Windows Installer will remove the component references. Then, if there are no more references for a component at the key path that this product installed it to, the resources making up that component at that key path are removed, using the definition from the package being uninstalled. It's important to note that no other components are checked to see if they reference the same files, which is why you must ensure that resources only ever belong to one component, ever, in the entire system. If you change the component GUID you must change the location or name of the key path so it doesn't interfere with the old version at all. It does make one concession to legacy, non-Windows Installer software - if you use SharedDllRefCount, the first time it places a reference to a given path it will add it to the SharedDlls key with a count of 1. Also, if it already existed in SharedDlls it will increment the count even if SharedDllRefCount is not set. Finally there are some standard directories (e.g. C:\Windows\System32) where it will increment SharedDlls regardless of SharedDllRefCount. Windows Installer does observe the protocol for SharedDlls so where above I've said the resources are removed it will decrement the reference count for the key path (if present) and only remove it if the count drops to zero. I'd only set SharedDllRefCount if you need to share the components with some pre-existing installation that doesn't use Windows Installer. The simplest route is to only use major upgrades, and not support multiple versions installed side-by-side. You use the Upgrade elements to detect the presence of a newer version and run a custom action type 19 (error custom action) to prevent installing an older version once a newer version is installed, and to detect an older version and run the RemoveExistingProducts action. The behaviour of your upgrade depends on where RemoveExistingProducts is scheduled. Typically it's scheduled directly after InstallInitialize, so that the old product is removed, then the new installed, but it's done in the install transaction so that if a problem occurs in installing the new version, the old is automatically reinstalled. It does mean that the old files are removed, then the new copied over. If you want to keep the existing files and only install changed ones, you have to schedule RemoveExistingProducts towards the end of the install transaction, after InstallExecute. However, you must be much more careful to follow the Component Rules so that the correct files are replaced. Read "Component Rules 101" in the WiX help file, and the "Default File Versioning" topic in the Windows Installer SDK. That log says that when you uninstalled version 1.0, the component cECWERM was installed, it was requested to be removed, and Windows Installer decided it should be removed. When you uninstalled version 2.0, the component wasn't installed, therefore no request was made and Windows Installer did nothing. That sounds a lot like having two different components (remember, the symbolic name means nothing to Windows Installer, it uses the GUIDs to track references) using the same key path. -- Mike Dimmick [EMAIL PROTECTED] wrote: > The only difference I can see in the logs is that version 1.0 has this > > Component: cECWERM; Installed: Local; Request: Absent; Action: > Absent > > And version 2.0 has this > > Component: cECWERM; Installed: Absent; Request: Null; Action: Null > > I'm inventing these version numbers obviously. This makes sense to me in > a way but I can see why it would also cause a problem. Version 1.0 > installed it so knows about it, version 2.0 didn't install it it was > already there so doesn't remove it. There is no mention of the reference > counting which I assume happens on a file basis not a compononte basis? > > Simon > > -----Original Message----- > From: Simon Topley > Sent: 27 February 2008 14:40 > To: 'wix-users@lists.sourceforge.net' > Subject: Reference counting issues > > Hello again all, > > I'm back sooner than I thought I would be, with a reference counting > issue. Imagine you had a software product, you release new versions > every 6 months so customers frequently run previous versions of the > software with current versions. Imagine now that you installed version > 1.0 then version 2.0. Now 1.0 is no longer needed so you uninstall 1.0 > but it takes components with it that are still in use by 2.0. These > components have the SharedDllRefCount set to yes, they have the same > guid as the newer version to. I am unsure if this is wise or not but > changing the guid doesn't seem to have changed the outcome. > > If we run the scenario is a more sensible order it works though. Install > 1.0, install 2.0, remove 2.0, common component is left. I have the logs > and I'm about to dig through them but I thought I'd quickly fire this > off incase there is something simple I'm missing here. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
