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
Sent: Tuesday, June 13, 2006 10:26 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Dark Bug?
Sent: Tuesday, June 13, 2006 10:26 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Dark Bug?
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.
__________________________________________________
Do You Yahoo!?
Tired
of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
