> in relation to the non file components are you referring to non file keypath > or components which simply contain additional resources but maintain a file > keypath ?
In general, I think I have a pretty good handle of the component rules / the best practices for laying out components like you mentioned below. What I wasn't aware of was the technical nuts and bolts of how things are actually layed out (registry keys, products mapped to component GUIDs, etc...). So to isolate the example, to answer your question, I would be refering to a component whose keypath is a non-file artifact, say a registry key for example. I know that there is a difference in behavior between non-file data (shortcuts, registry keys, ini keys, etc...) and file data (actual files that get installed). So I was looking to further understand the actual techincal merits of how this fits into the picture; or even if this fits into the ref-counting picture at all. (maybe everything fits the ref-counting picture, but some other magical MSI process treats files differently, etc...). Or, in other words... > when you uninstall a product it simply removes its product reference from > under the component. where there are no products left it will remove the > component. > > As such two products sharing the same component will not allow removal of > a > component unless both products are uninstalled. So if you uinstall > ProductA > without uninstalling ProductB you should find the component stays > installed. The above logic does make sense. However, when two products share the same component, but install that [file based component] to different locations on the file system, this is not the case. (File installed by Product A will be uninstalled regardless whether ProductB is or isn't uninstalled). Assuming this relates to Windows Installer ref-counting, I was seeking to understand how this is accounted for. [Refer to the 'really stupid example' with sample WiX code I posted under the same subject]... ~~~~ Phil Wilson's book I thought was an entertaining read. I wasn't aware there could be more than one "Definitive Guide to Windows Installer" :) Thanks for the note, I'll have to check out the "Darwin" version.... ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of jmcfadyen [EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 11:17 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Component Rules to be honest i dont have a good answer for that question. even if there was a good answer there is no tools currently on the market which could rectify the problem even if it existed. for example lets "assume" non file based components should be matched, how would a tool determine that the content of the component was the same in order to complete the match in the first place. this is a very difficult result to achieve even if there was a clear guideline on what was to be done. I would be surprised if automated methods would deal with this well. but what I can add is a few others peals of wisdom accumlated from various respected sources on the subject. a good reference worth reading is Darwin Sanoy's & Jeremy Moscawitz "definitive guide to windows installer" not the Phil Wilson version (not that his is not good just that this particular topic is covered quite well by Darwin). You can get this guide at http://www.realtimepublishers.com. The Wise Package Studio conflict management suite covers the component rules quite well and offers some good techniques (not available in wix that i am aware of) in resolving component rule issues. some of their techniques are. Splitting components Where 2 components have the same keypath but not necessarily the same content different components should be stripped from the component and placed into a 3rd component. for example Component A FileA.dll Component B FileA.dll Extrafile.txt the extrafile.txt should be placed into a new component. Matching Keypaths where components have the same content but different keypaths the keypaths should be matched Component A FileA.dll = kp FileB.dll component B FileA.dll FileB.dll = kp In this example keypaths should be matched. Any perhaps even splitting components to separate (this is probably not a great example just trying to highlight a point) Shared DLL Setting the shared dll attribute on all components from memory this is either 8 or 16 I can never recall and dont have an SDK handy. This allows reference count to be handle using Windows Ref count mentioned earlier (this is completely different to Windows Installer Component counts) and allows for multiple installation media types to reference count (i.e. items other than windows installer used with Windows installer) in relation to the non file components are you referring to non file keypath or components which simply contain additional resources but maintain a file keypath ? regards, John John Nannenga wrote: > > OK, what would the recommended approach be for non-file based components > and their GUIDs, considering backwards compatibility with respect to > multiple instances? > > > [How does path (for file based component data) come into the picture? ] > > ________________________________________ > From: [EMAIL PROTECTED] > [EMAIL PROTECTED] On Behalf Of jmcfadyen > [EMAIL PROTECTED] > Sent: Wednesday, July 16, 2008 9:15 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Component Rules > > hi all, > > I think you may be getting confused with reference counting here. There > are > two different types of reference count available. Once is windows based > and > the other is windows installer based. > > Windows reference counting is handled by setting a registry key which > monitors file actions. > Windows Installer reference counting is handled at the component guid > level. > > Each component is recorded during installation and each product that > installs that component is listed under the component. Where you have two > products installing the same component both of those components parent > products will be listed under the component detail. > > for example > > <ComponentA> > <ProductA> > > <ProductB> > > when you uninstall a product it simply removes its product reference from > under the component. where there are no products left it will remove the > component. > > As such two products sharing the same component will not allow removal of > a > component unless both products are uninstalled. So if you uinstall > ProductA > without uninstalling ProductB you should find the component stays > installed. > > this is considerable detail written about this process here where you can > prove this functionality for yourself. > > http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!136.entry > > now in relation to having two component with different files sharing the > same GUID this is not recommended by ms. component guids should only be > matched where files have the same filename & path this is regardless of > version. For example if your have ProductA and ProductB both sharing > MSCOMCTL32.OCX of different versions both components should have the same > GUID where the File (predominantly DLL's) are backwards compatible. > > So if you had multiple Products which have the same file in the same path > of > different version they should all share the same component GUID assuming > backwards compatibility. Where a file is using the same name but is not > backwards compatible the GUID's should not be matched. In many cases only > the dev will know this information. > > > > John Nannenga wrote: >> >> I believe component ref-counting for file based data is handled at the >> product code and location level. That's why Chad see's the results he >> does for the below situation regarding the web.config file. >> >> >> Component ref-counting for non-file based data (registry information, ini >> keys, shortcuts, etc...) is based upon the component GUID. If you have >> two registry keys (or shortcuts, etc...) ('A' and 'B' for example) both >> with a GUID of 'FOO'; although 'A' and 'B' might be two entirely separate >> keys, Both will be written. However, at uninstall, only the last to be >> uninstalled, will be uninstalled. >> >> >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Baker >> Sent: Wednesday, July 16, 2008 11:50 AM >> To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net >> Subject: Re: [WiX-users] Component Rules >> >> Chad, >> >> The situation you describe is exactly what we will be doing. All 30 of >> these web applications get installed to the same machine, all to >> different >> locations on the file system. Until yesterday I believed exactly as you >> have stated, the second application updating the Component reference >> would >> cause problems, which is why i have all the duplication between the >> projects. After testing with 2 scaled down wix package projects and one >> library project what I have found is this. >> >> Install WebApp1 - web.config is in correct location for WebApp1 >> Install WebApp2 - web.config for WebApp2 is in correct location, >> web.config for WebApp1 remains untouched. >> Uninstall WebApp1 - web.config for WebApp1 is properly removed. >> Uninstall WebApp2 - web.config for WebApp2 is properly removed. >> >> It doesn't matter which app i uninstall first, the behavior is correct. >> This has been tested with config files and .NET assemblies, the behavior >> is the same. >> >> This is not the behavior i expected, but now that i have found that this >> is what happens, i am very tempted to consolidate the components to the >> common library as mentioned earlier. >> >> Thanks, >> >> Steve >> >> ---------------------------------------- >> >> From: Chad Petersen <[EMAIL PROTECTED]> >> Sent: Wednesday, July 16, 2008 11:05 AM >> To: [EMAIL PROTECTED]>, "General discussion for Windows >> Installer XML toolset." <wix-users@lists.sourceforge.net >> Subject: RE: [WiX-users] (no subject) >> >> Steve, one possible risk is as follows. It'll likely happen if you >> install any two MSIs that contain the same Component, but a different >> file, on one computer. The first MSI will set the Component reference. >> The second MSI will alter that Component reference to point to the new >> file. Then if you uninstall the first MSI it will probably remove the >> copy of the file from the second installer with it. >> >> You can mark Components as Permanent and it might leave them alone. >> >> Since it is not a DLL I don't believe the RefCount would help at all in >> this situation. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Steve >> Baker >> Sent: Wednesday, July 16, 2008 8:19 AM >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] (no subject) >> >> Hey all, >> >> I find myself in a situation where I need some feedback on component >> rules. I have over 30 solutions that each have a wix installer project >> in them. each solution is a web site that is deployed automatically and >> internally. right now i have a ton of duplication between each of the >> install projects and am looking to reduce the maintenance overhead. i >> have a common wix library project that i have moved the UI and some >> launch conditions into. I'd like to move more into this common location >> but i get stuck with this particular situation. >> >> each project contains many components that look like the following: >> >> < Component Id = " StagingConfiguration " Guid = " >> 935B1135-E34D-49DA-843E-D984B8F2C5ED " DiskId = " 1 " > >> < File Id = " staging.config " Name = " web.config " Source = " >> $(var.Web.UI.ProjectDir)staging.web.config " /> >> < Condition > STAGING >> >> If i moved that component (and i have at least ten more just like it) >> into my common wix library each web project would have the same >> component guid for its web.config file. I have read over the component >> rules again and again and can't find anything specific about doing this, >> but it still seems like there is something fundamentally wrong with the >> idea. >> >> I would appreciate if somebody could let me know what the risk is with >> having more than one msi contain a component with the same guid (and a >> different file). I have nobody here that understands windows installer >> to bounce the idea off. >> >> Thanks, >> >> Steve >> >> ------------------------------------------------------------------------ >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> > > -- > View this message in context: > http://www.nabble.com/Re%3A-Component-Rules-tp18491876p18500279.html > Sent from the wix-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Re%3A-Component-Rules-tp18491876p18501288.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
