Building and Distributing. |
|
|
|
Building and Distributing. |
|
|
Building and Distributing. |
|
|
|
Building and Distributing. |
|
|
|
|
||
User's Guide - Chapter 9: Building and Distributing
Once you have created your Visual Patch project and configured all relevant options, the only two steps left are to build your patch and distribute it.
Building your patch is made easy using the built-in Publish Wizard. For more advanced cases, you can customize the build process through the Build Settings dialog, which gives you access to many advanced features such as build configurations and pre/post build steps. Whatever route you choose, Visual Patch makes building your patch a seamless part of the development process.
Once your patch is built, you must distribute it to your users. This chapter will introduce you to both the standard and advanced aspects of the build process, and will get you well on your way to distributing your patch
Visual Patch’s ultimate goal is to produce the smallest patch possible. When you choose to build your patch, all of the files in your included versions are first verified and then analyzed. Visual Patch begins analyzing at the latest version in your patch, and compares all previous versions’ files to the ones in the latest version.
Depending on what the previous versions contain, files listed in the most current version are either not included in the final patch, are partially included in the form of diff files, or are included in their entirety. This ensures that the patch is of the smallest size possible while maintaining compatibility with all desired previous versions.
After analyzing all of the included files, diff files are created for any file existing in all versions but which is not the same across all versions. These diff files are created using Indigo Rose’s proprietary binary differencing compression engine. If a file exists in the latest version that does not exist in one or more previous versions, the complete file is included in the patch. Lastly, if a file exists in all versions, and is unchanged across all versions, it is not included in the patch.
During the build process, the files to be included – both diff files and complete files – are compressed into the final single patch executable. It is important to note that the sum of the diff file sizes will never be greater than the individual file’s calculated compressed file size. In other words, if Visual Patch can create a smaller patch by simply compressing an entire file rather than including diff files, it will include the entire file.
With the goal of making the build process as seamless as possible, Visual Patch includes a Publish Wizard to assist you.
The first screen of the publish wizard prompts you for the location that you would like to publish to, as well as the name of the file that you would like to create.
Note: If your project contains more than one build configuration, the wizard will prompt you to choose which build configuration you want to use before it starts.
The second screen of the publish wizard allows you to select which versions will be built into your patch.
This is a very important step in the build process. It allows you to individually include or exclude each of the versions in your project from the built patch executable.
Being able to specify which versions are included in your patch is extremely useful. For example, imagine you have a product that has been updated fifteen times. Including all of these versions in your patch could potentially result in a rather large patch. On the other hand, creating a patch that applies only to the last three previous versions would be a substantially smaller file.
The wonderful thing about the Visual Patch build process is you don’t have to choose between building a complete full history patch and building a patch applicable to only a few of your past versions. Build one, launch the build wizard again, and easily build the other! Then, let the user decide which patch they should download, or better yet, incorporate TrueUpdate (www.trueupdate.com) into your software and have that decision made automatically, without any user interaction required.
When the Next button is clicked, Visual Patch begins building the patch.
Once the build process is complete, the following summary screen is displayed. This screen presents a summary of the build process and displays any errors.
Once you are finished viewing this screen, you can click Finish to dismiss the build wizard. If the Open output folder option is checked, the output folder will be opened automatically, giving you instant access to the generated files.
Tip: If you need more information or want to trace an error, you can view the entire build log file by clicking the Build Log button.
The Build Settings dialog, accessible by choosing Settings from the Publish menu, allows you to set the defaults you would like to use for the build process. Basically, any setting affecting the final built patch file is found here. If you opted to publish without using the publish wizard, this is where you must specify your build settings. These settings are organized into tabbed sections in the Build Settings dialog: Output, Constants, Pre/Post Build, and Optimizations.
All of your patch output settings are located on this tab. You can specify where your final patch executable will be built to by adjusting the Location settings. Enabling the encrypt patch archive data option encrypts your patch data with a random key during the build process, helping to hide and further protect your information. The Versions to Build setting allows you to specify which versions will be built into the final patch executable.
Constants are essentially design time variables. They are similar to session variables, but instead of being expanded as the user runs the patch, they are expanded when you build the project. In other words, when you build your project, all of the constants are automatically replaced by the values assigned to them.
You can define constants on the Constants tab of the Build Settings dialog.
Clicking the Add button displays a dialog where you can name the constant and give it a value.
Each constant has a name that begins and ends with a # sign, and an associated value. The name will be replaced by this value throughout the project when it is built. It’s exactly like a big search-and-replace operation that happens whenever you build the project.
Since each constant is essentially just a name that gets replaced with different text, you can use them just about anywhere. You can use them on screens, in file paths, in actions…pretty much anywhere that you can enter text.
One of the many timesaving features of Visual Patch is the ability to define build configurations. Build configurations allow you to define different build settings for your project and switch between them easily.
For example, it’s often useful to have a build configuration for each type of patch that you wish to build. One build configuration could create a full-history patch, capable of updating all previous versions (e.g. 1.0, 1.1, 1.2, 1.3, 1.4) up to the current version. Another could be an incremental patch to bring the previous version up to the current one (e.g. from 1.4 to 1.5). A third could be a multi-version patch to bring two common previous versions up to the latest version (e.g. from 1.2 or 1.3 to 1.5). You could then build each type of patch by switching between the build configurations.
Note: Files and folders can also be associated with specific build configurations on their Conditions tab. This makes it easy to conditionally enable or disable the patching of specific files within a version.
You can add a build configuration to the current project by clicking the Add button near the top of the Constants tab of the Build Settings dialog.
The values that you assign to constants are specific to each build configuration. In fact, this is what makes constants so useful. By assigning different values to the constants in each build configuration, you can make sweeping changes to your project by simply selecting a different build configuration when you build it.
Note: The build configuration determines which values are used when the project is built.
Here are some things you can do with constants and build configurations:
• use constants in the paths for your source files, and use different versions of the files for different build configurations (professional version vs. standard version patch)
• use actions that test the value of a constant named #DEBUG#, and set it to true in a "Debug" build configuration and false in all other configurations. Then you can leave helpful debugging code in your scripts, and only have it performed when you build the Debug configuration. For example:
function MyFunc()
nCount = nCount + 1;
if #DEBUG# then
Debug.ShowWindow();
Debug.Print("Inside MyFunc() - nCount = " .. nCount);
end
end
Constants are extremely useful for performing unattended builds because they can be changed using a command line argument. You can even use constants to specify the output location, and which build configuration to use. The possibilities are endless.
For example, you could create a batch file that would generate a unique patch for every one of your customers, with the customer’s name showing up on one or all of the screens during the patch.
For more information on performing unattended builds of your project, search for "Unattended Build Options" in the Visual Patch help file.
There may be instances where you want to run a program either before or after you build your patch. Visual Patch makes this process easy through Pre and Post Build Steps. On the Pre/Post Build tab of the Build Settings dialog, you can set a program to Run Before Build, and a program to Run After Build.
The uses of this feature are limited only by your imagination. You could, for example, launch a program that would compare all files from your company’s development network to the files about to be patched to ensure the most up-to-date files are included – the program could alert you if the local files do not match those on the network. You would want this program run at the last possible second to ensure last-minute bug fixes are not left out. Alternatively, you could have Visual Patch call an FTP client program with command line arguments to automatically upload your latest patch to your website. The possibilities are limitless.
You can specify the path to the desired program in either of the Run Program fields. Any command line arguments that are needed should be specified in the Command Line arguments fields. If you want Visual Patch to ‘sleep’ while the other program is open, check the Wait for program to finish running checkbox.
There are a number of size and speed optimizations on the build settings dialog that allow some control over the build process. For example, enabling the "Cache diff files" and "Cache compressed file sizes" options allow Visual Patch to store any binary difference files that it creates so it only needs to perform the delta compression once for each file, instead of every time the patch is built.
Enabling the "Cache diff files" option stores the generated diff files in a folder on your system so they can be reused the next time you build, instead of having to be generated again. Subsequent builds of the same project are much faster when this option is enabled.
Likewise, Visual Patch calculates the compressed file size of each file and compares this value to the total size of all the diff files that are generated for that file. Enabling the "Cache compressed file sizes" option stores the compressed size information so it doesn’t need to be recalculated the next time you build the project.
The Multipass Diff Creation options determine whether Visual Patch will perform multiple passes on each file in order to achieve the smallest possible diff size. Each successive pass will look for longer patterns in the file, which, depending on the internal structure of the file, may result in better compression.
Since each pass adds to the creation time, you can limit the multipass optimization so it is only performed when the initial pass takes less than a specific amount of time. This is known as the "Initial pass time threshold."
The "Maximum additional passes" option controls the maximum number of additional passes that will be attempted in order to search for successively longer patterns.
Tip: For best results, enable the "Cache diff files" option and set the "Initial pass time threshold" to 0 so the multipass optimization will be performed for every file, but only the first time you build the project. This will allow Visual Patch to generate the smallest diff files, and will still allow subsequent builds to be performed as quickly as possible.
The Low Memory Scenario options allow you decide how you want Visual Patch to behave in low memory situations. You can choose to favor small patch sizes or shorter build times. In general, it is best to keep this set to "Minimize patch size," however you may wish to change the setting on systems with limited memory resources if you find that your builds are taking a very long time to complete.
Tip: For large files, the size of the generated diff files depends on your computer’s available memory. Because of this, it is recommended that you clear out the diff cache by clicking on the Clear Cache button whenever your computer hardware is upgraded.
To control how Visual Patch handles the build process, you can modify the build preferences by choosing Edit > Preferences from the menu.
You can use the build preferences to control whether Visual Patch opens the output folder by default, disable the publish wizard and, when not using the wizard, control whether a confirmation dialog is displayed before the build process begins.
One of the most important and often overlooked steps when creating a patch is testing it after it has been built. You should test your patch on as many computers and operating systems as possible. Try it on every operating system that your software product supports. All versions of windows have differences between them, and should be thoroughly tested. As well, test your patch on systems with a lot of hard-drive space and on those with a very limited amount of hard drive space. And lastly, test your patch on a system where the defaults for your program’s installation were not used. For example, install your software to C:\SomeDirectory\ and then patch it. Does your patch fail, or does it work as expected?
If you have made use of Visual Patch’s multilingual support, be sure to test out each language in your install.
Many problems with patches have simple causes, such as forgetting to include a file, or moving a file to an incorrect location. Often a runtime problem is simply due to the patch being unable to locate the files to patch. Care must be taken when designing the directory structure of your patch, ensuring that it is compatible with the installed software being patched.
If you do run into a problem with your patch, test it on as many systems as possible to narrow down the problem. You might discover a common factor between the systems that is causing the patch to fail.
Tip: For information related to tracking down script-related issues, see Debugging Your Scripts in Chapter 10.
Once you have thoroughly tested your patch, it is time to distribute it. There are several ways to distribute your software patch, but the four main media are floppy disks, CD-ROMs, DVDs, and the Internet.
Preparing your patch for distribution is as easy as publishing to a hard drive folder. Once the build operation has completed, simply copy the patch executable to your desired media, and you are ready to go! Or, if you have opted to distribute via the Internet, simply take the generated patch file and upload it onto your website for your customers to download.
For an automated patch delivery system, consider TrueUpdate. TrueUpdate incorporates easily into any windows-based application, and allows the user to check for updates through your software application. Or, your application could use TrueUpdate to check for updates periodically. TrueUpdate supports either a wizard, dialog, or silent interface.
TrueUpdate isn’t just an easy way to let your customers know software updates are available; it can automatically select the best patch to apply. For example, consider a product that has experienced fifteen version changes. You may choose to publish one full history patch, and one patch that updates the last three versions to the most current version. TrueUpdate can check the user’s version and download the appropriate patch, potentially saving you bandwidth costs and your users time.
For more information on TrueUpdate, please contact Indigo Rose Software or visit the TrueUpdate website at www.trueupdate.com.
Learn More: Indigo Rose Software - Visual Patch - Buy Now - Contact Us