It's more complicated than that. The problem your hitting in WiX v3 is actually a feature added in WiX v2 that allows a developer to separate their authoring into separate "Fragments" and have everything get stitched back together. In WiX v1 the best you could do was to separate authoring out into Merge Modules and try to merge everything back together. This "symbol/reference feature" implemented WiX v2 was what allowed WiX v2 scale to the needs of Office way back in 2003.
On top of the scalability improvements, that feature has an additional (usually) desirable feature of informing the developer when a required piece of the setup (such as an Custom Action definition) is missing. Unfortunately, in your case, the improper separation of code in the Merge Modules means those references are broken. As Bob noted, you could switch to .wixlibs and then the WiX toolset would be able to resolve references. Merge Modules are limiting in their design here. It isn't about morals, it's about correctness and limitations in the various designs (both in MSI and in WiX). To carry your analogy of editing with Orca to native code, it is not possible to link a .cpp with code that buried in a compiled DLL (i.e. not code that is exported from the DLL). The link.exe will fail telling you it can't resolve reference and will not generate an executable. Now you could probably go in with a hex editor and make everything work at the assembly/machine code level. Just like in this case, you can go in and hack at the MSI with Orca but light.exe won't be able to help you. Finally, migrating from WiX v1 to WiX v2 is a large undertaking. Migrating from WiX v2 to WiX v3 is pretty straight forward (and WixCop can help *a lot*). WiX v1 didn't have half of the concepts that WiX v2/v3 has and was about half as powerful as WiX v2/v3. I'm sorry it was surprising that there is lot of work to migrate from WiX v1 to WiX v2/v3 but anyone that lived through the migration would have told that it wasn't going to be easy. -----Original Message----- From: Tina Basinger [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2008 12:48 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions from Merge Modules It seems to me that Wix is being unsupportive of something that Windows Installer allows. The InstallExecuteSequence table of an MSI contains references to both the custom actions defined in the MSI directly as well as in the merge modules. You can go in and modify this table directly (using Orca) however you like, and the MSI essentially doesn't know whether an item in the table was merged in from a merge module or directly by the install. Thus, in my opinion, Wix is not allowing something that Windows Installer fully supports, and this seems wrong to me. I'm not suggesting that it is good design to code things such that a merge module defines a custom action, and the main install schedules it. I'm just suggesting that Wix is attempting to force people into a good design, and in this case i don't appreciate it. It's like you're forcing some sort of moral standard on me rather than letting me make that decision (and possibly mistakes) for myself. Our install is really old and minimal maintenance is only done as needed. I've just upgraded it from Wix 1.0 to Wix 3.0 (like I said, it's an old install...), and am running into many issues due to the poor design choices that were originally made, but were allowed by Wix 1.0. These issues relate around the fact that our main install can no longer schedule the merge module custom actions. We have 3 main installs consuming our merge modules, and some of the merge module actions are scheduled in different orders or with different conditions (usually based on main install properties) between the various installs, so I really cannot move the scheduling of these items into our merge modules. For these, i've pulled the custom action definitions into a wix fragment so that I can keep the scheduling in the main install. But then there are other custom actions that I have had to leave defined in the merge modules and schedule them there because they set merge module properties. But scheduling these is becoming a problem because the order depends on other custom actions that are now scheduled by the main install. It's a mess! So, as you can see, upgrading to wix 3.0 is giving me a much bigger headache than I foresaw, which is why I'm a bit perturbed that the wix toolset is forcing this moral standard upon me, especially since it didn't in the (very) old days. And yes, our install is obviously very poorly designed (not by me), but so far it's worked for us, and it's just going to take a bit more work than I thought to get it working with wix 3.0. Thanks for listening to me grumble... -Tina On Wed, Sep 24, 2008 at 10:29 PM, Bob Arnson <[EMAIL PROTECTED]> wrote: > Tina Basinger wrote: > > Maybe this is not supported any more. Should I be able to have the main > > installation code schedule a custom action that is defined within a merge > > module? Any thoughts? > > > > Merge modules are designed to be self-contained, which is why they have > the modularization GUID attached to their IDs. They should schedule > their own custom actions. I'm not aware of any way to do what you want > with WiX, except using .wixlibs instead of .msms. > > -- > sig://boB > http://joyofsetup.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 ------------------------------------------------------------------------- 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