|
Upon further investigation into this
issue, you appear to be correct about the correlation of the Revision Number
summary info property and the modularization guid. This means that the
way WiX currently generates merge modules is wrong (and has been wrong for a
very wrong time). I need to investigate further, but it
appears that either the Module/@Guid or Package/@Id attribute should not be
allowed for merge modules (since it seems like they are supposed to match –
which actually makes a lot of sense). We may need to do a slightly
painful fix in the 3.0 schema for this issue – I’m not entirely
sure of the implications of this information to WiX. The decompiler’s logic shouldn’t
change very much though – it should still look at the guid appended to
identifiers to determine the guid of a merge module since this is the one that
will most visibly affect consumers of the merge module (given that the revision
number summary info property is throw out during merging). I’ll
still need to see a merge module that doesn’t work with the decompiler to
understand why it’s not picking up the module guid properly – that seems
like a likely bug. Thanks, Derek From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone The package code of an MSM file is not the
same thing as the Module/@Guid. PackageCode The decompiler never persists a
PackageCode because its supposed to be unique for every single MSM/MSI/PCP file.
Even if you link the same MSI twice in a row, the guid is supposed to
change. That is why it shows up as all question marks in the Package/@Id value. For merge modules, its
not important to persist the package code exactly since its lost during
merging. For product files, there is one rare scenario in which its
useful to persist the package code - if you are attempting to create a 100%
identical WiX-built version of an MSI file that was previously built with
another tool. However, this is a very rare scenario and its possible to
do by manually updating the Package/@Id after
decompilation (there is no automatic support for this because its so rare that
supporting a flag would likely mean it was done when it shouldn't). Module Guid The value in Module/@Guid
is the modularization guid for a merge module. This is the string like
".000C1109_0000_0000_C000_000000000046" which is appended to all
identifiers in a merge module. I've heard rumors (but never confirmation)
that sometimes the appended guid string uses different characters for the
underscores. The decompiler currently wouldn't handle that since it only
sees appended guids with underscores. If there is a common character
used besides underscores, the decompiler should support that character as well
so that it will work with modules built by more tools. The decompiler
would also need to display a warning in that scenario because WiX only creates modularization
guids with underscores (which is according to Windows Installer guidelines), so
you wouldn't be able to 100% round-trip the MSM file (but this should affect
functionality for properly authored merge modules). If the issue was that the merge module
did contain modularized entries (no appended guid), then the decompiler should
likely display a warning about that so that the user knows they need to specify
a Module/@Guid manually (I'd still like to
avoid having the decompiler automagically generate one for you). Could you please take a closer look at
your merge modules with issues to see if any of these issues exist? If
so, then it would be super-helpful if you could attach an affected MSM to a bug
or email so I can work on getting dark to work better with an actual
example. This would also be useful for finding out if there are any other
issues with the decompilation of real-world MSM files. Thanks, Derek From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Christopher Painter In a previous message I talked about Dark not extracting the Package ID
from MSM's. Try this: ( Using Dark 3.0.1703.0 ) and Orca 3.0.3709.371 Create a New MSI database using ORCA and look at the Summary
Information Stream to validate that it was a ProductCode. Save the database as
an MSM. Execute: dark test.msm test.xml -v2 Note that there are no errors, just a message saying that it's
decompiling the _SummaryInformation table. Look at test.xml and observce that the Module Package ID attribute is
<??????-??????? ectera > If you try to candle the XML you'll get an error saying that the Module/@Guid attribute was not found. This is just a quick example. I have dozens of MSM's that have all of
their correct attributes and pass validation but dark/candle simply won't work
on them. __________________________________________________ |
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
