I think you might be mixing concepts. In wixlib files, there are no appended guids (there don't need to be because collisions are detected directly). You should never have to refer to things with their appended guids in WiX authoring. The modularization should just happen when appropriate in the binder (this runs after the linker, so there are no appended guids in the linker at all).
Derek
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Shmarya Rubenstein
Sent: Monday, July 31, 2006 12:33 AM
To: Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Launch Checkbox
On 7/30/06, Bob Arnson < [EMAIL PROTECTED]> wrote:
Shmarya Rubenstein wrote:
> - A set of merge-modules for various "software components".
The first question: Do you need merge modules at all? They complicate
things, as you've discovered, and with .wixlibs, they're not necessary
unless you need to distribute them outside your organization.
You have to link to create a merge module, so WiX has to resolve all the
references. .wixlibs can have "dangling" references up until you link,
which would solve this problem.
> What seems to happen is that when linking the merge-module, the entire
> ExitDialog is brought into the module and 're-branded' to be GUID
> qualified. IE: I end up with a bunch of
> "ExitDialog.CF74FF55_B670_488B_85AE_785C01C14AFB " Dialog keys all
> over the show. Most importantly, for the DoAction event in the
> ControlEvent table.
Yes, that makes sense. It's legal to have a dialog in a merge module.
Having a control event for a dialog would create a reference to the
dialog. So when you link the module, WiX would pull in the referenced
sections.
> When the merge-module is linked into the actual MSI build (which also
> has the wixui.wixlib linked so taht it can display UI), ExitDialog is
> *again* brought into the final MSI, such that there are both "
> ExitDialog.CF74FF55_B670_488B_85AE_785C01C14AFB" and "ExitDialog"
> Dialog keys.
Again, that makes sense from the WiX perspective -- they're two
different dialogs. Light has to treat merge modules as black boxes, so
it can't know that the dialog is one it already knows about.
Another approach
would be to keep all your UI in one section (presumably the product).
You can keep the CA in the module and then publish the DoAction control
event from the product.
Trying to do this, I can't get light to resolve the reference to the CA. If I open the msm in Orca, I see that the CA is there with the name LaunchConfig.CF74FF55_B670_488B_85AE_785C01C14AFB, but light keeps throwing me:
error LGHT0094 : Unresolved reference to symbol 'CustomAction:LaunchConfig.CF74FF55_B670_488B_85AE_785C01C14AFB' in section 'Product:5AFDD87C-1600-49FE-9C1E-100EB105BAF1'.
Perhaps the light engine deals with UI elements (or their wixobj equivalents) before dealing with the Directory/Feature elements which reference the merge-module... Either that or its just a bug?
Any ideas?
--
sig://boB
http://bobs.org
--
Shmarya
-----------------------------------------------------------
[EMAIL PROTECTED] - http://shmarya.net
NUnit rocks! http://nunit.com
--
Shmarya
-----------------------------------------------------------
[EMAIL PROTECTED] - http://shmarya.net
NUnit rocks! http://nunit.com
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
