What you've described below is the most common usage scenario for WiX: shared authoring is broken up into fragments which are included in various places as needed. WiX was designed around this usage pattern.
The desire to split things into small wixlib files and have the pragma functionality is only a reaction to what is likely a bug in the linker (duplicate symbol errors). You should be able to combine all your fragment-level authoring into one huge wixlib file and link that with various products to create individual msi files. This method has no impact on the build scripts - moving files and registry keys around is completely handled within the wix syntax after that. This is the approach I would suggest for this scenario. However, I understand that you've encountered some problems with it, so we'd need to see the combinations of wixlib files or wxs files or whatever else is necessary to reproduce this problem ourselves so we can diagnose it in the debugger. Thanks, Derek -----Original Message----- From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 9:15 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] 'Duplicate Symbols' error, Components,and ComponentGroups Maybe our flaw here is that we were viewing wixlibs like merge modules. We were wanting to have them be self-containing pieces that could individually be included in projects without having to know the specific details of that piece. Lets say that our end goal here is that we'd like to have one wixlib per windows installer feature. If a new project needs a feature that is already created and used in some other install, you simply reference the feature in the install wxs file, include the wixlib when linking, and you've got everything that needs to be done for that feature to work properly on the customer's machine. Let me give an example here: We've got an intersystem messaging framework that our products use to communicate with each other. We've got our server piece and we've got the client piece. That client piece will need to be installed with lots of different applications. So we create a component group that includes all necessary files, registrations, etc. that the client piece needs in order to run properly. We now include that component group in any Feature wixlib that will need to send and receive messages and link with all the needed wixobj files (corresponding to the components). Now lets say that that client messaging piece gets modified and there is a new file that needs to be installed in order for the client to be able to send and receive messages. We first add that new file (component) to the client messaging component group. And now we need to go to every feature that uses that component group and we have to add the appropriate wixobj file corresponding to the new component. If we had one wixlib per install, then we'd have to add that new component wixobj file to any install that uses the client messaging piece. If we had the #pragma directive that was mentioned before, then each component group, feature, etc. would be it's own self-containing item and all we would have to do is add the new component wixobj file to the client message component group wixlib and every feature that uses that wixlib would have the new component included. So one change would change every feature/install. I understand that with the current functionally if we did have feature-level wixlibs and multiple features in an install included the client messaging component group, that we'd still have linker errors (duplicate symbols). But I was just using it as an example to show the potential of wixlibs if a #pragma directive was created. -----Original Message----- From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 3:03 AM To: Wilson, Brad; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] 'Duplicate Symbols' error, Components,and ComponentGroups Brad, The exception you hit below is an issue I saw a few weeks back. I thought I checked in the fix already but I guess not (probably part of a bigger change which is on hold). At any rate, I'll fix that issue right away and it will get better testing in the future (the change which fixed it used the functionality as well). Regarding the problems you're hitting with component groups - we really need to have some repro files to try it out. You can open a bug on SourceForge and attach the necessary files there. It's a bit more cumbersome than sending them via email but I'm certain it works because people have attached files this way in the past. Regarding the pragma request - why are you breaking up wixlibs so small that management of them is an issue? Just make the wixlibs as big as manageably possible because wix will automatically pull out what it needs. Keep in mind that a wixlib file can contain as many wixobj files as necessary (not just a single componentgroup). In Office we sometimes had wixlib files that were several hundred megabytes large. It was great because we knew we could just throw everything in there and let the linker sort it out. Derek -----Original Message----- From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Sunday, July 16, 2006 7:27 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] 'Duplicate Symbols' error, Components,and ComponentGroups ok i've tried to send this message twice now with the attached zip files but it bounced back both times (stating that messages w/zip files are being blocked. i also tried changing the attachment to .txt but that failed too). After reading the following, please let me know if you'd still like to see the wxs files and i'll just send them one by one. One thing that I failed to mention (and you'll notice this in the scenarios), that we are using wixlibs for all features, component groups, etc. And if two features include the same ComponentGroup wixlib or component wixobj, then we get the 'Duplicate symbol' error. We completely understand that this is how C++ works when linking and thus, how wix should work as well. Our goal is to design this so the msi author doesn't have to care what Components, ComponentGroups, etc. are in the Feature. They just include the Feature wixlib and they're done. The way that it is designed now, the msi author will have to include every wixlib that the feature uses (Because we clearly can't include those wixlibs in the Feature wixlib because they can be included in multiple features). So at this point we're asking if we can get something similar to #pragma (comment lib ... ) and lib path notions that C and C++ use. We'd like a new wix node (something like WixLibRef) that will specify the exact wixlib filename that should be pulled in via light.exe whenever someone uses the containing wixlib. Light will then search a wix lib path to find the specified wixlibs. This would allow the msi author to only have to include the feature wixlib. It might sound trivial, but as development continues and we add more component groups to our features, the new dependencies will ripple up and cause the msi authors to have to modify the makefiles (light args) for every msi that needs that feature. As component groups are added, we'll get breaking errors. But as component groups are removed, the msi author wont have any indication that he has unnecessary wixlibs included. This would GREATLY benefit us for our next product release. Up to this point, everything we have done is for 'proof of concept' and we are getting ready to begin converting 30+ installs to WiX. Lastly, Rob you asked for the stack dump from light.exe when using the -ai commnad line parameter. Here that is: light.exe : error LGHT0001 : Object reference not set to an instance of an object. Exception Type: System.NullReferenceException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Field.IsIdentical(Field field) at Microsoft.Tools.WindowsInstallerXml.Row.IsIdentical(Row row) at Microsoft.Tools.WindowsInstallerXml.SectionCollection.FindEntrySectionAn dLoa dSymbols(Boolean allowIdenticalRows, IMessageHandler messageHandler, Section&entrySection, SymbolCollection& allSymbols) at Microsoft.Tools.WindowsInstallerXml.Linker.Link(SectionCollection sections) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Tools.WindowsInstallerXml.Field.IsIdentical(Field field) at Microsoft.Tools.WindowsInstallerXml.Row.IsIdentical(Row row) at Microsoft.Tools.WindowsInstallerXml.SectionCollection.FindEntrySectionAn dLoa dSymbols(Boolean allowIdenticalRows, IMessageHandler messageHandler, Section&entrySection, SymbolCollection& allSymbols) at Microsoft.Tools.WindowsInstallerXml.Linker.Link(SectionCollection sections) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main(String[] args) ________________________________ From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 4:58 PM To: Wilson, Brad; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] 'Duplicate Symbols' error, Components,and ComponentGroups For each of these below scenarios, if you could make small wxs files to reproduce each problem, that would greatly speed up investigation because then we could just run the repro in the debugger to figure out what's going on. A lot of this stuff sounds like bugs, but I'd have to see the scenario in the code to be sure. Derek ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Brad Sent: Thursday, July 13, 2006 1:03 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] 'Duplicate Symbols' error, Components,and ComponentGroups wix version 3.0.1828.0 When calling light against install projects there are a few situations that are causing problems for us when designing our installs. All of these situations cause the "Duplicate Symbol found' error. Situation 1 (this is pseudo-code): Feature1 - ComponentRef1 - File1 - ComponentRef2 - File2 Feature2 - ComponentRef2 - File2 - ComponentRef3 - File3 <Product ...> <FeatureRef id="Feature1" ... > <FeatureRef id="Feature2" ... > </Product> This is causing a Duplicate symbol error on File2. It was my assumption that components could belong to multiple Features if using <ComponentRef>. Situation 2: If I were to create a ComponentGroup and include File2 in it and then use <ComponentGroupRef> in Feature1 and Feature2, I would also get the 'Duplicate Symbol' error but this time it would be on the ComponentGroup. Situation 3: I'm not sure that this last situation is a bug. But it's something that I would hope would work or it might undermine our usage of nested component groups. In our situation there are a lot of files that belong to many different applications. Our hope was to be able to nest ComponentGroups to be able make a modification to one ComponentGroup and have it affect lots of different installs. Here is the situation: ComponentGroup1 - ComponentGroupNest1 - ComponentGroupNest2 ComponentGroup2 - ComponentGroupNest2 - ComponentGroupNest3 <Feature ...> <ComponentGroupRef id="ComponentGroup1" /> <ComponentGroupRef id="ComponentGroup2" /> </Feature> We were hoping that light would be smart enough to understand that, since those files are included from multiple ComponentGroups, to just ignore any multiples of that file for that feature. Instead, we get the Duplicate symbol error on ComponentGroupNest2. I've tried all of this with the -ai command line option for light.exe but i'm getting a SystemNullReference exception. To get this to work, is -ai supposed to be used or should the three situations work w/o a specific command line option? Brad Wilson | Developer phone & fax +1.317.715.8523 | [EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
