Patch

[rcowart]

In testing the Installaware, I made and installed a build that uses web media blocks. The main exe size resulting from that build was 1.7 meg. There were multiple web media blocks of varying size.

To test the patching, I changeed the revision number, included the previous build as a patch reference, and added one new small file to the new build.

When I selected new build, the resulting patch exe was 8 meg in size and appeared to include all the files from all the web media blocks in the patch build. Is this normal behavior?

From reading your help files, I would have thought it would have built a very small differential patch file adding only the one new small file.

[CandiceJones]

You wouldn't normally end up with a file that size at all. Setup projects have conditional defines in the script which automatically exclude certain items like runtimes from the build. I imagine you removed some of those defines while working on your project, so you ended up with a huge monolithic file.

You can create a new project from a template and test with that one - also take a look at the template code to see where the default defines are and how they are used.

You are free to customize everything for your own requirements of course, as illustrated by your case.

[rcowart]

Your answer did not help at all. Documentation on the patch process in your help files is very minimal. What process does the patch builder go through in determining what is included in the patch file. Please don't tell me it is in the script as it is not. There is a single script call to build the patch and nothing else and no explanation of what happens.

What is included in a patch? Is it only files that have changed or does it include a whole web block if one file in that block has change?

Or is it truly a binary patch, changing only the portions of files that have changed?

[sinan]

This is how patching works:

1) When you click Build Patch, your setup project is compiled with the BUILDMODE compiler variable set to PATCH
2) This automatically excludes certain script commands from your setup (such as pre-reqs), you are free to customize this behavior to your liking by editing the script
3) Once the project has been built, the second stage starts: comparing with the previous builds, added as "Patch References"
4) Each Patch Reference is decompressed, and then all your old versions, and the latest built version, is compared at the byte level
5) The result of this binary differential scan is encapsulated in an MSP file, which is packaged into your final patch setup, along with your built script

Patches are built as single monolithic files only (no web media blocks), and they contain only the portions of files that have actually changed across all your patch references and the latest build.

Hope that helps!

[rcowart]

Yes, that did help quite a bit. Thanks.

If I change whether the web media blocks are compiled from one version to the next (because they have not changed, are large, and I don't need new copies), will this affect the patch process.

Do all web media blocks need to be resident in the same local directory as the older version exe when doing a patch or is there enough info in the msi to locate add download the older web media blocks if needed during the patch process? Do I even need to hang on to older web media blocks or just the older exe?

It would be very helpful if you guys could come up with a good pice of documentation on the patch process and how it works.

[sinan]

Web media blocks must be present in the folder right next to the EXE files, so the patch process can extract them successfully and run the binary comparison.

Not compiling web media blocks should not have impact on the patch process as long as the current web media blocks are available alongside all the patch references.