I was just looking at how the linker actually loads mergemod.dll, which is a
COM component library, not a flat DLL. As far as I can see, light.exe loads
it via a manifest (light.exe.manifest) and the shipped mergemod.dll (at
least in the binaries.zip, version 3.0.3790.371 as of WiX 3.0.3502.0) has a
manifest that lists the contained class and interfaces.
The manifest mechanism won't work at all on Windows 2000 because it was
added in Windows XP. If running on Windows 2000, you should consider adding
a light.exe.local file to force the local copy to be loaded, otherwise
you'll get whatever version is registered on the system, which could be out
of date.
Wasn't there recently a change to the MSBuild tasks so they run in-process?
How is the COM manifest handled in this case? Are you sure that it will be
processed when light.exe is run through AppDomain.ExecuteAssembly? I have a
feeling that it's an unmanaged mechanism based on the actual process startup
image file name and again you'll bind to the wrong mergemod.dll.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 17 January 2008 06:18
To: Chris Houser (HIS)
Cc: Kishore Chaliparambil; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX v3 - ModuleInstallExecuteSequence table not
merged correctly
I'd expect it to work but then the linker lets mergemod.dll do all the heavy
lifting of merging modules, so it's a bit of a black box. Or a big, huge
black box.
-------------------------------------------------------------------------
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
