Melt a Product, corrected wixpdb does not update <Merge> paths. #5501
Comments
|
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 elements from wixpdb. I mean all the contents inside the merge module itself get put in the wixpdb, but the .msm we point to merge in, could that be suppressed safely? This sort of data is in the wixpdb specfically and I was wondering if it served much purpose, |
|
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 table, melt.exe will update the path in the wixpdb accordingly where I tell it. see: msm_faked_as_binary_in_wixpdb.png But my problem is with .msm files themselves being merged in via the typical tag, it won't update the .wixpdb presumably since it doesn't show up anywhere in the table since the contents of the .msm are merged in and the .msm itself isn't actually an installable file (eg: no corrected "P00Bits" path to look for the extracted file since it's not extracted (why would it be its a whole .msm, I get that part). 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... 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) The wixpdb does actually a record, but all the data is missing like it was cleared somehow (which I was assuming Binder.cs does before writing the wixpdb).I tried hacking around and doing the same thing for "WixMerge", but when I actually got it to not put that WixMerge table in the wixpdb, the result was it not merging the contents of the merge module itself at all into the MSI. The runtimes from the merge module didn't show up in the File/Component/etc tables and tables such as ModuleSignature did not show up. So this wasn't the correct change at all, but again I was just hacking around getting familiar with light.exe and the wixpdb generation process. |
|
For my comment above, attaching a screenshot didn't take. The screenshot I was trying to show can be seen a few comments above that (the part I'm referring to is the top section that's mostly highlighted text). Sorry for the confusion. |
|
What's the error message? It's surprising that Pyro cares about rows from unreal tables. |
|
Running: pyro.exe -delta -reusecab -cc D:\builds\eic_2017r1_team_ref.pyro.systest\gen\MSP\WFMRTAIntegration\P00Bits ReleasePatch\DefaultPatchConfig.wixmsp -out ReleasePatch\WFMRTAIntegration.msp -t BaseToSU ReleasePatch\DefaultPatchDiff.wixmst D:\pulse\data\agents\ibuild13_1\recipes\444735810\base\int\src\wixlib\merge_modules\microsoft_vc100_atl_x86.msm.wxs(5) : error PYRO0103 : The system cannot find the file 'D:/builds/installcommon_2017r1_team_ref.pyro.p00\pub/gen/resources/merge_modules/Microsoft_VC100_ATL_x86.msm'. |
|
Full set of commands for reference: "Melt" Running: melt.exe D:\builds\eic_2017r1_team_ref.pyro.systest\products\eic\install\msi\WFMRTAIntegration\ReleasePatch\LocalPTP\WFMRTAIntegration_2017_R1.msi -out ReleasePatch\WFMRTAIntegrationCorrected.wixpdb -pdb D:\builds\eic_2017r1_team_ref.pyro.p00\pub\gen\install\packages\Release\pdbs\WFMRTAIntegration.wixpdb -x D:\builds\eic_2017r1_team_ref.pyro.systest\gen\MSP\WFMRTAIntegration\P00Bits -xn WFMRTAIntegration_2017_R1.msi / WFMRTAIntegration.wixpdb "Torch" Running: torch.exe -p -xi ReleasePatch\WFMRTAIntegrationCorrected.wixpdb D:\builds\eic_2017r1_team_ref.pyro.systest\pub\gen\install\packages\Release\pdbs\WFMRTAIntegration.wixpdb -out ReleasePatch\DefaultPatchDiff.wixmst "Candle" Running: candle.exe @d:\builds\eic_2017r1_team_ref.pyro.systest\gen\logs\install\MSP\WFMRTAIntegration\ReleasePatch\candle_compilerargs -out ReleasePatch\DefaultPatchConfig.wixobj D:\builds\installcommon_2017r1_team_ref.pyro.systest\pub\resources\install\DefaultPatchConfig.wxs "Light" Running: light.exe @d:\builds\eic_2017r1_team_ref.pyro.systest\gen\logs\install\MSP\WFMRTAIntegration\ReleasePatch\light_binderargs ReleasePatch\DefaultPatchConfig.wixobj -out ReleasePatch\DefaultPatchConfig.wixmsp "Pyro" Running: pyro.exe -delta -reusecab -cc D:\builds\eic_2017r1_team_ref.pyro.systest\gen\MSP\WFMRTAIntegration\P00Bits ReleasePatch\DefaultPatchConfig.wixmsp -out ReleasePatch\WFMRTAIntegration.msp -t BaseToSU ReleasePatch\DefaultPatchDiff.wixmst |
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.
The text was updated successfully, but these errors were encountered: