Re: [WiX-users] How does patching decide which files to include in msp?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

The easiest way (although not the fastest) to get a binary wixpdb file is to
make sure that your WXS that contains your Product element doesn't contain
any files (not even in the Binary table) and that you build all your WXS
files that have any kind of file in them into "binary WIXLIBS" (use the -bf
flag on the lit.exe tool). Then link those wixlibs with your .WIXOBJ file
compiled from your WXS file containing the Product tag into your MSI.
Unfortunately, the binary WIXPDB still doesn't contain the files from Merge
Modules without a change to the wix toolset itself, so those files are not
so easily patched (there is a way, but it is much more work).

Torch compares database rows, it does not compare the files themselves. The
file comparison is done by Pyro, but that requires one of two things:

1) The file source paths are different between the two builds AND that the
source paths from the earlier build are still available for the Pyro tool.
Or
2) The files are embedded in the WIXPDB. There is no option to force files
into the WIXPDB, but all files that come from wix-style bound sources
(Wix-provided extensions and others built using the same bound-library
model, binary WIXLIBs, binary WIXOUTs) will automatically always be included
in the wixpdb (barring any bugs).

Files where the File table row changed *should* also be patchable when NOT
using "binary delta" patching (which you aren't) even without the old file
for comparison simply because the File table row is different. Any changes
to the corresponding MsiFileHash table *should* also make the file
patchable, but I'm less sure of that working (I didn't write that part of
the code, and I haven't fully investigated it either). However, having the
old files present will always make the file patchable, and is a requirement
to use "binary delta" patching.

Now, I have not touched on using any *Ref elements under the PatchFamily
element. If you use any (even one) *Ref element in your patch authoring
under the PatchFamily element, files/components or Binary elements not in
the same fragment as the referred-to element may not be included in your
patch.

-----Original Message-----
From: Oleksandr Y. Nechyporenko [mailto:ale...@gm...] 
Sent: Saturday, September 25, 2010 11:45 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How does patching decide which files to include in
msp?

Blair,

1. I use the following syntax:

"$(WIX)Bin\torch.exe" -p -xi
"$(ProjectDir)Installers\Base\ProductSetup.wixpdb"
"$(ProjectDir)Installers\Latest\ProductSetup.wixpdb" -out
"$(ProjectDir)Obj\ProductSetup.wixmst"

"$(WIX)Bin\candle.exe" "$(ProjectDir)ProductPatch.wxs" -out
"$(ProjectDir)Obj\ProductSetup.wixobj"

"$(WIX)Bin\light.exe" "$(ProjectDir)Obj\ProductSetup.wixobj" -out
"$(ProjectDir)Obj\ProductSetup.wixmsp"

"$(WIX)Bin\pyro.exe" "$(ProjectDir)Obj\ProductSetup.wixmsp" -out
"$(ProjectDir)Installers\Latest\ProductPatch.msp" -t PRDTRS 
"$(ProjectDir)Obj\ProductSetup.wixmst"

Where
"$(ProjectDir)Installers\Base\ProductSetup.wixpdb is wixpdb created during
build of previous version
"$(ProjectDir)Installers\Latest\ProductSetup.wixpdb" is wixpdb created
during build of new version

2. The source paths in the two wixpdbs the same. I.e. "modified" file and
"base" file it is same file located in same physical path.

BTW, I'm not sure, with what torch compare modified file? I've thought that
wixpdb contains "old" copy of file. But now I've noticed that size of wixpdb
is too small to contain copy of all base files. Does it contains hashes of
files?

----------------------------------------------------------
Best Regards,
Oleksandr Y. Nechyporenko

-----Original Message-----
From: Blair [mailto:os...@li...] 
Sent: Sunday, September 26, 2010 1:05 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How does patching decide which files to include in
msp?

Some quick questions:

1. When calling torch, is the "-p" argument used? Without that, pyro may not
see the file or other data it needs to do its job.
2. Are the source paths in the two wixpdbs the same or different? Are the
wixpdbs "bound/binary" (so that the older version of the file is not
overwritten by the newer build)? Without actual different files accessible
to pyro, its binary comparison routine may conclude that the files are not
different.

The binary comparison routine by default (you can change it via an extension
that provides a different BinderFileManager) is:

        /// <summary>
        /// Compares two files to determine if they are equivalent.
        /// </summary>
        /// <param name="targetFile">The target file.</param>
        /// <param name="updatedFile">The updated file.</param>
        /// <returns>true if the files are equal; false otherwise.</returns>
        public virtual bool CompareFiles(string targetFile, string
updatedFile)
        {
            FileInfo targetFileInfo = new FileInfo(targetFile);
            FileInfo updatedFileInfo = new FileInfo(updatedFile);

            if (targetFileInfo.Length != updatedFileInfo.Length)
            {
                return false;
            }

            using (FileStream targetStream = File.OpenRead(targetFile))
            {
                using (FileStream updatedStream =
File.OpenRead(updatedFile))
                {
                    if (targetStream.Length != updatedStream.Length)
                    {
                        return false;
                    }

                    // Using a larger buffer than the default buffer of 4 *
1024 used by FileStream.ReadByte improves performance.
                    // The buffer size is based on user feedback. Based on
performance results, a better buffer size may be determined.
                    byte[] targetBuffer = new byte[16 * 1024];
                    byte[] updatedBuffer = new byte[16 * 1024];
                    int targetReadLength;
                    int updatedReadLength;
                    do
                    {
                        targetReadLength = targetStream.Read(targetBuffer,
0, targetBuffer.Length);
                        updatedReadLength =
updatedStream.Read(updatedBuffer, 0, updatedBuffer.Length);

                        if (targetReadLength != updatedReadLength)
                        {
                            return false;
                        }

                        for (int i = 0; i < targetReadLength; ++i)
                        {
                            if (targetBuffer[i] != updatedBuffer[i])
                            {
                                return false;
                            }
                        }

                    } while (0 < targetReadLength);
                }
            }

            return true;
        }

If you know a better routine, or a way to improve this one, please open a
bug.
-Blair

-----Original Message-----
From: Travis Gaff [mailto:tr...@pc...] 
Sent: Friday, September 17, 2010 4:49 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How does patching decide which files to include in
msp?

Thanks for the reply.
Just to be clear this is not an install time issue in which certain files
are not updated because their modification times have changed.  I am able
to extract the .msp file immediately after creation and confirm that files
are not included that I wish to include.  Applying the patch in Orca shows
the same issues.  It looks like this is occurring at the patch assembly
level.

-----Original Message-----
From: Tony Juricic [mailto:TJu...@Tr...] 
Sent: Friday, September 17, 2010 3:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How does patching decide which files to include
in msp?

These are not WiX rules but MSI rules and are documented on MSDN site,
somewhere in install patching section.

-----Original Message-----
From: Travis Gaff [mailto:tr...@pc...]
Sent: Thursday, September 16, 2010 12:48 PM
To: wix...@li...
Subject: [WiX-users] How does patching decide which files to include in
msp?

Hello WiX users,

I am trying to construct a .msp file to patch a several hundred file
installation.  However I am finding that a large number of files are not
ending up in the final .msp file.  Right now I suspect many of these are
due to both the new and the old version of the file having the same
version number; we're fixing this.
However I have some files that do not have a version number and do have an
internal change but are not in the msp.  They appear to have little
difference from most of the other files, they're all added with individual
components to a .wxs by our build system.

How does WiX decide which files to include in a patch using the pyro/torch
method?

By comparing several files I suspect it does the following:
1) if a file has a version number, check it, if same version skip file
2) if file doesn't have version number but there is a size difference:
patch it? (I haven't verified this)
3) if no version number AND file is same size: diff the file or use
creation date? 

What rules does WiX use to determine which files should be included in the
msp?

Background:
All components are in 2 features.  The 2nd feature is a sub-feature of the
first and right now I am not even looking at its 2 shortcuts.
The *patch.wxs file includes: 
  <ComponentRef Id='co_mainui.exe' />   (a component of the main feature)
  <PropertyRef Id='ProductVersion'/>   (to update the ARP program version)

The patch is generated using .wixpdb files with torch and pyro:
  candle patch.wxs -dcodepage=1252 -ext WiXUtilExtension
-dtop_projects_dir=C:\projects

  light -o out.wixmsp -cultures:en-us -ext WixUIExtension patch.wixobj
-ext WiXNetFxExtension -ext WiXUtilExtension
-dtop_projects_dir=C:\projects

  torch -t patch -p -pedantic -xi build1.wixpdb build2.wixpdb -out out.mst

  pyro out.wixmsp -out out.msp -t patch out1.mst

I am using 3.5.1916.0, however I had similar issues in 3.0.

Thank you for any help you can offer.

Travis Gaff,
Software Engineer
PC-Doctor, Inc.  
9805 Double R Boulevard, Suite 301
Reno, NV 89521

CONFIDENTIALITY
The information contained in this message is confidential. It is intended
to be read only by the individual or entity to whom it is addressed or by
an authorized designee. If the reader of this message is not the intended
recipient, be aware that distribution of this message in any form is
strictly prohibited. If you have received this message in error, please
immediately notify the sender and destroy any copy of this message. 

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS:
TRAD) of three operating subsidiaries, TradeStation Securities, Inc.
(Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a
trading software and subscription company, and TradeStation Europe
Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None
of these companies provides trading or investment advice, recommendations
or endorsements of any kind. The information transmitted is intended only
for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender
and delete the material from any computer.

--------------------------------------------------------------------------
----
Start uncovering the many advantages of virtual appliances and start using
them to simplify application deployment and accelerate your shift to cloud
computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users