Thanks Mike, It turns out (though I am yet to test this) that version 2.0 never attempted to install the component because of a version check I put in place. This is third party software that we ship with our product and I needed to detect it's presence as many of our customers will have it installed seperately direct from the company that makes it or have it installed with another package much like ours. I have put two checks in, one that this software is installed and another to detect the version. The installer sees that the current version is installed so ignores the feature, thus no count is incremented. I'll test this theory shortly.
Simon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 27 February 2008 16:16 To: Simon Topley; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Reference counting issues 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. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software is strictly prohibited. Wallingford Software is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. Registered in the UK, company no: 02288719 Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA ------------------------------------------------------------------------- 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
