Open chadmiles opened 7 years ago
I've also used !(bindpath.MergeModPath), since that part's a little confusing in the doc as to which needs to be used. Assuming !(bindpath) is the correct way and not just !(bind).
What do you mean by "suppress information from the output wixpdb"?
Sorry, what I was trying to say was suppress any
This sort of data is in the wixpdb specfically and I was wondering if it served much purpose,
<Merge Id="microsoft_vc100_crt_x86.m" FileCompression="yes" Language="1033" DiskId="1" SourceFile="FindFirstInDirs(TIER_ROOT_INSTALLCOMMON, pub/gen/resources/merge_modules/Microsoft_VC100_CRT_x86.msm)" />
Still not getting it. You want to suppress the merge module content from being recorded in the .wixpdb? Or the reference to the merge module? What problem are you having with the current behavior?
The reference to the merge module itself. It's linked into the MSI as you build it, and then the contents merged of it merged into the MSI.
The problem stems from our GA/MSI wixpdb having a path to the merge module, SourceFile="FindFirstInDirs(TIER_ROOT_INSTALLCOMMON, pub/gen/resources/merge_modules/Microsoft_VC100_CRT_x86.msm)". But that path won't exist during our patch builds since it will be a path from GA/MSI build area. If it were suppressed when building it wouldn't be an issue for Patch# build.
For instance, let's say I put this in the
see: msm_faked_as_binary_in_wixpdb.png
But my problem is with .msm files themselves being merged in via the typical
see: msm_in_wixpdb.ping
I guess after playing around with Melt, the best way to say this might be, since WixMerge is an unreal table can it be dropped from the wixpdb when generated by Light.
Thanks.
So what happens today? What's the problem you're seeing?
When building our MSIs, we point to a merge module for VC runtimes to merge into our installs.
Light drops an unreal table called WixMerge I believe from the final MSI. But the wixpdb generated for that MSI has a table definition still for the WixMerge table. Screenshot below from wixpdb...
![Uploading 2a641dda-fcee-11e6-9306-e3993770d806.png…]()
Can this table be dropped from the outputted wixpdb? Since it's an unreal table that doesn't actually exist in the MSI.
The problem is that path in the wixpdb is for our GA MSI, D:\builds\installcommon_2017r1_team_ref.pyro.p00\pub\resources\merge_modules\Microsoft_VC100_CRT_x86.msm.
When we go to build our patches, that path above will not exist anymore on our build machine. Only thing we'll have access to is the P00 MSI and the P00 wixpdb.
When using Melt to extract the contents of our P00 MSI, an update our P00 wixpdb, it handles everything else just fine. The File/Icon/Binary tables. But the .msm it cannot extract from the MSI since it doesn't exist in the MSI (eg: the WixMerge table is unreal and dropped from MSIs). So we can't extract it to a new intermediate path and we can't update the wixpdb accordindgly to point to that intermediate path, the P00Bits in other words.
The error I get when building the patch is coming from Pyro when it says it can't find the file:
D:\builds\installcommon_2017r1_team_ref.pyro.p00\pub\resources\merge_modules\Microsoft_VC100_CRT_x86.msm
Since that is a P00 (MSI build) build path that won't exist for P01+ build machines that are for patches. And since we can't melt the .msm that doesn't exist in the .msi, we're stuck at this break at the moment. That's why the only idea I had that makes the most sense would be a flag to light.exe, something like -swixmerge, that does not write records for the WixMerge table into the wixpdb.
FWIW, I believe this is similarly done in Binder.cs for the _Streams table. It clears the rows from the table or something like that prior to saving the wixpdb? Maybe that's a guess at this point. I believe the code is something like:
if ("_Streams" == table.Name) { table.Rows.Clear(); }
The wixpdb does actually a
3.11
Using melt to extract files for wix patching, I'd like to see a way to suppress information from the output wixpdb if possible. When running melt, it can't pick up whole .msm files that don't actually exist in the MSI for obvious reasons since their contents are merged in instead.
I've had a previous issue getting wix patching to work and am past those other issues after upgrading to 3.11, but this seems to be the last issue I'm having. I honestly don't know of any way of getting this to work short of decompiling .msm's into componentgroups (not desirable at all especially for things such as Crystal Reports that's 10's of thousands of lines of wxs code). Or trying to find how to hack the wixpdb myself via melt.cs to update the paths for things pulled in for building an MSI with , which doesn't get updated by melt.
If this is even possible, provide a flag to suppress putting information into an output wixpdb. I'm not sure if there's reasons why it would be needed, my intuition would say it's not needed or at the very least can be an override flag for those who found that useful.
Or if there's other ideas to get past this I'm all ears. I tried setting up bind paths but ran into a weird issue, which if is resolvable might be easier for me.
-bMergeModPath=D:\builds\foo -bMergeModPath=\share\bar
D:\builds\foo won't be around when we build patches, it's our P00/GA build area that we can't save due to space. \share\bar could exist for us if I could get further but as mentioned I'm stuck on one issue.
When passing the bindpaths to light.exe, it corrupts part of the D:\builds\foo path and puts a garbage character in place of "\b". I think it might not escape correctly and believe it to be a backspace? I need to do some more testing on this to be sure. is the character replacement.
To make matters more interesting, I tried using a different path such as C:\users\ to avoid that possibility and it still could not find the !(bind.MergeModPath) value passed to light (it was passed). I'm not sure if that's because I'm not using it on a File element but a Merge element w/ the SourceFile attribute.