#1185 Light fails to link merge module.
This defect occurs when using WiX version 3.0.4025.0 or 3.0.4014.0. I can verify that this defect does not occur using WiX version 3.0.3829.0.
I have created a Wix product which integrates a merge module published by "Data Dynamics Active Reports for .NET 3.0".
I am not able to attached the merge module to this defect report due to its file size. When light attempts to link the merge module, it reports the following error with stack trace:
errorLGHT0001: Failed to fetch a File row from the database that was merged in from a module.
Exception Type: System.InvalidOperationException
Stack Trace:
at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String tempDatabaseFile, Output output, FileRowCollection fileRows, StringCollection suppressedTableNames)
at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile)
at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file)
at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args)
Binder temporary directory located at 'C:\Users\autobuild\AppData\Local\Temp\pz4wquhn'.
Validator temporary directory located at 'C:\Users\autobuild\AppData\Local\Temp\uxsp3tis'.
Discussion
Logged In: YES
user_id=26581
Originator: NO
Are you using arn3_528351msm or arn3_528352msm (the latest for .NET 1.1 and 2.0) or some other version?
Logged In: YES
user_id=2076144
Originator: YES
Using arn3_528352msm.
Logged In: YES
user_id=26581
Originator: NO
OK. Can you go back to 3.0.3829 or 3.0.3907 and copy mergemod.dll from the 3.0.4014 bin directory? We're trying to figure out if the bug is in mergemod.dll or with changes we introduced in the last couple of weeks about how light.exe loads mergemod.dll.
Logged In: YES
user_id=2076144
Originator: YES
Ok. I copied mergemod.dll from the 3.0.4014 installation bin directory into the bin directory of a 3.0.3829 installation. Looks like the version of mergemod.dll used in WiX 3.0.4014 is 4.0.6001.17131 (compared to the version used in WiX 3.0.3829 which is 3.0.3790.371).
When attempting to run the installer with the replaced DLL, the error occurs again:
"light.exe : error LGHT0001: Failed to fetch a File row from the database that was merged in from a module.".
Does this mean that I should be able to use the latest version of WiX (3.0.4025) if I replace mergemod.dll with an older version? Will this likely be your course of action for resolving the issue? Is mergemod.dll a Microsoft assembly?
Please excuse the verbosity of this post; I want to be sure I've done exactly what you were suggesting.
Test project that tries to reproduce the problem
Logged In: YES
user_id=26581
Originator: NO
That sounds right. If a prior version of mergemod.dll works, the bug is likely in mergemod. But I haven't been able to reproduce the problem, even with the same version of ActiveReportsDistrib.msm. Can you try the product.wxs sample I attached to this bug? I used the following command line:
candle.exe product.wxs & light.exe product.wixobj
(ActiveReportsDistrib.msm has some ICE39 warnings but no other errors.)
File Added: product.wxs
Logged In: YES
user_id=2076144
Originator: YES
Strange. I can't replicate the problem with the product.wxs file you attached, but I am still able to replicate it with my WiX product. The inclusion of the merge module within my product is defined similarly to product.wxs with the following differences:
1.) <merge ...=""> does not contain the FileCompression="yes" attribute. Removing this from produt.wxs still did not replicate the issue.</merge>
2.) <mergeref ...=""> is only used once, in the top-level feature (i.e., it is not also in a sub feature). Again, running light having removed the two other <mergeref ...=""> references in product.wxs did not replicate the issue.</mergeref></mergeref>
What other differences might I look for between my WiX project and the simple example you attached? The installer I'm creating is quite complex. It uses IIS and Util WiX Extensions, and is comprised of 21 wxs files (most of which are fragements with UI dialogs). Perhaps another notable difference is that my product uses <advertiseexecutesequence ...=""> and <installexecutesequence ...=""> and does not contain the <ensuretable ..=""> elements which product.wxs defines.</ensuretable></installexecutesequence></advertiseexecutesequence>
Logged In: YES
user_id=991639
Originator: NO
The problem is that you have a conflict on the PIDKEY property.
It appears the Merge Module is trying to merge in a property that is not correctly modularized (missing the .MODULE_ID on the end) and is colliding with the property in your MSI or from another Merge Module that didn't follow the spec either. Talk to the vendor of the Merge Module to get a fixed Merge Module.
Logged In: YES
user_id=2076144
Originator: YES
Hi Robmen,
I haven't seen any errors which report, 'Error: Failed to merge Row: PIDKEY into Table: Property'.
I'm also a little unclear on what the PIDKEY property is. Can you please elaborate? The Active Reports Merge Module is the only merge module I'm using. In the event that the vendor (Data Dynamics) is unable to "correctly modularize" the merge module in my timeline, is there something I can do to my project to ensure that there will be no 'PIDKEY' conflicts?
Thanks!
Logged In: YES
user_id=991639
Originator: NO
Sorry, I must have got this bug mixed up with another bug. In the merge.log file, look for the line(s) that start with ">>" for all of the errors.
Logged In: YES
user_id=26581
Originator: NO
Check build 3.0.4123.0 or later; I reverted to a prior version of mergemod.dll that fixes a similar bug (1965131).
Logged In: YES
user_id=2076144
Originator: YES
Hi Bob,
Yes, the latest build resolves the issue I was having. Thanks!
What's the best way for me to monitor whether future versions will "re-upgrade" the version of mergemod.dll being used?
Logged In: YES
user_id=26581
Originator: NO
Good news. We won't update mergemod.dll until/unless the bug is fixed.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 15 days (the time period specified by
the administrator of this Tracker).