Re: [WiX-users] Extract files from msi (Msiexec, not WIX issue... .)

Derek Cicerone Tue, 13 Jun 2006 09:07:40 -0700

Christopher,

I'm sorry, but I think its a particularly unfair comment to say that a bug in dark was "scoffed to the side". I believe the particular issue you are referring to dealt with dark creating output that when compiled immediately produced errors. I would like to explain why that was done.

The WiX 2.0 decompiler made several attempts to "repair" poor authoring, fill in missing gaps, and basically do whatever was possible to make a decompiled msi file work in candle. However, over time, it became apparent that this approach had several disadvantages:

1. The "fixes" that the decompiler made sometimes involved shortening identifiers to make them fit within the prescribed limits of MSI validation checks. However, these shortened identifiers were not always a welcome change as in the case once or twice when I needed a decompiled VS merge module to exactly match the msm file it came from. With the 2.0 decompiler this was nearly impossible because it kept "helping me". Another issue with the shortened identifiers was that it only mostly worked. Since identifiers are used throughout an msi file including formatted fields, cabinet files, and foreign keys, the decompiler invariably did not catch all the instances and thus I would hit issues during installation of the reconstituted msi that previously had worked just fine. Yet another problem with this particular fixigin logic was that it was a naive truncation and sometimes this resulted in collisions in the new identifiers which of course only got caught in the linker! So overall, fixing identifiers in the decompiler - not a particularly good idea.

2. Putting fixing logic in the decompiler requires it to keep up-to-date with the compiler. This means that everytime we validate something a bit more strongly in the compiler, the decompiler must also have the matching check. Over the course of the WiX 2.0 cycle, we learned that having to make these changes in two locations - first in the compiler, then in the decompiler to ensure the problem didn't get hit in the compiler - did not work because someone always forgot the decompiler (who thinks of the decompiler when they are working on the compiler - no one). Even if the developers all started recognizing that issues need to be fixed in both the compiler and decompiler, there is still the issue of maintaining code with similar logic in multiple places - a sure recipe for additional regressions and mistakes - particularly for the decompiler since its really only ever used once in the life cycle of a product - right up front.

That being said, the very particular issue that you hit, if the archives indicate correctly, was basically that the decompiler failed to set the category for a custom table's binary column to "Binary". The reason it did not set the column to "Binary" was because the merge module from which the authoring was decompiled did not set the category to "Binary". The compiler displays an error if a binary column is not marked as "Binary" because such authoring will fail ICE validation in the linker. The compiler is trying to help you out by displaying an error as early as possible so that you don't have to deal with it at a (in some groups much) later time when validation occurs. One discovery we made from your bug report was that the documentation for creating binary columns in wix authoring was inadequate because it did not indicate that the category must be set to "binary" in order to avoid a compiler error. I still have this bug in my query and hope to fix it along with some other documentation bugs soon. This is a good bug. However, its important to point out that the original msm file most likely did not pass MSI validation and therefore the input into dark was buggy. The best way to avoid this problem in the future: run validation on your MSI/MSM/PCP files before running it through dark.

WiX strives to give users the very best MSI/MSM/PCP files possible so that they will not encounter additional issues when they go to actually install those files on customer's machines. There are a lot of places in the pipeline of wix tools where these quality checks could be made, however, it makes the most sense to do them as early as possible (for groups with long pipelines and highly distributed authoring) and in one place if possible (to avoid confusion over how an error was detected, avoid duplicated code, avoid different behavior in different checks, etc...). I'm very sorry that you feel like the particular issue you hit was "scoffed to the side" but I hope you can now understand that there is an overarching design to how everything operates and while individual pieces may seem a bit inconvenient at times, the hope is that once you get into the wix ecosystem it all just works.

Thanks,

Derek

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter
Sent: Tuesday, June 13, 2006 7:59 AM
To: [EMAIL PROTECTED]; 'Simon Topley'
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Extract files from msi (Msiexec,not WIX issue... .)

Sure, I've tried that. Unfortunatly Dark and Candle disagreed on what `valid` MSI code was and the compiler and linker couldn't reassemble what Dark created without alot of hand jamming. I even reported this as a bug but had it scoffed to the side as `works as designed.`

Rob Mensching <[EMAIL PROTECTED]> wrote:

Have you looked at dark (the WiX toolset decompiler)? Dark v3 is particularly solid. It will drop all of the files and .wxs authoring in such a way that the compiler and linker can put it all back together.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley
Sent: Tuesday, June 13, 2006 2:26 AM
To: 'Christopher Painter'
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Extract files from msi (Msiexec, not WIX issue... .)

I have had limited success with MSI2XML. The latest build seems to have installer realted issues but the build before that is stable. It does extract all teh files (including files desine for the windows and system directory, sadly it names them all by the File ID, I suppose I could go through renaming all of the file ID's to there longnames.. This Highlights another issues for me (this applies to the Admin installers too "msiexec /a"). Both of these methods extract the files into a different directory structure from the one used to construct the msi file. So even if I do get one of these to work I will still have to monkey around with the files before I can use them to build a patch from... I'm starting to think that keeping an uncompressed version of any released installers is the only way to do this patch business.

Thanks for the help all the same, if anyone has anything further to add to this, please do...

Simon Topley

From: Christopher Painter [mailto:[EMAIL PROTECTED]
Sent: 12 June 2006 14:54
To: Simon Topley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Extract files from msi (Msiexec, not WIX issue... .)

This open source project MSI2XML does a pretty good job of exporting an MSI database to XML and extracting all of the streams to a subfolder. Once you've done this you can see the CABs that are stored in the MSI and extract your files from them.

On 6/12/06, Simon Topley <[EMAIL PROTECTED] > wrote:

Hello all,

I know this isn't really a WIX problem, however it must be an issue others have seen. "Msiexec /a" is used to create an administrative installer (i.e uncompressed into folders). This little gem works pretty well for the most part, however it never extracts files destine for the windows or system folder... At first I thought it was because of the old condition of the feature (default being 0 not 1) I've changed that and still only get the "Pfiles" folder out or my msi file...

Is there any other way to extract the files from an msi file that anyone knows of?

For fun I've included a fragment that adds a file to the windows directory, in case someone spots a fundamental problem :

    <Fragment Id="fWindowsFiles">
        <Directory Id="WindowsFolder" Name="WinFldr">
            <Component Id="cHTMLHelpExe" DiskId="1" Guid='B2975E71-5581-4E13-B850-2731A2EFA122' >
                <File Id="file1065" Name="hh.exe" src="" />
            </Component>
        </Directory>

    </Fragment>

Kind Regards

Simon Topley

The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them.

_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
http://geekswithblogs.net/vagmi.mudumbai
http://installneo.blogspot.com

"Peace is its own reward." - Mahatma Gandhi

The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them.

--
http://geekswithblogs.net/vagmi.mudumbai
http://installneo.blogspot.com

"Peace is its own reward." - Mahatma Gandhi _______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them.

Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.

_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Extract files from msi (Msiexec, not WIX issue... .)

Reply via email to