Thinstall offers a number of method for updating your application after it has shipped.
Method 1: Using Patch Files.
A binary patching application will study 2 sets of files (your old version and your new version) and produce a list of difference between these two sets. The differences are compressed and stored along with a small application in a single EXE which is then delivered to your customer via the internet or update disk. This update is known as a Patch and when it is run by the user (or automatically by your application), the patch will reconstruct a new image of your files.
When you use Thinstall, a binary patching application works to upgrade one compressed EXE to another compressed EXE. Although it only operates on one file, without knowing it, the patcher will be upgrading all of the file changes you made to the archive. Thinstall has special compression options to allow patchers to create a minimum distribution size for your patch file. For more information see the section Effect of Compression on Software Patching.
The advantages for using Patch files are:
1. Patches provide the lowest bandwidth method of doing updates. Because patch files only contain the changes you made, not the original files, your bandwidth transmission or disk space requirements are typically much lower than distributing complete copies of the files you wish to modify.
2. Patches occur as an "all or nothing" event, so the user is never left in a partially upgraded scenario. If you plan to upgrade individual files make sure that you can roll back the old files in the even you can't successfully upgrade all files.
3. Patches work on Thinstall's encrypted and compressed data so you never have unprotected data on the user's hard drive. If you plan to upgrade files by replacing them with external files you leave the door open to someone who might tamper with the files and makes changes that compromise your security.
4. The deployment logic for patch files is very simply. Sample pseudo code might look something like this:
if (get_new_patch("http://mycompany.com/patch/XYZ.exe")
{
run_process("XYZ.exe");
ExitProcess();
}
No matter how complex your upgrade process, if you utilize Thinstall's virtual filesystem and virtual registry very little else needs to be done. The code above would work without and changes to upgrade your application from to version 2.0+ of the .NET Framework as Thinstall adds support for future versions of the .NET Framework.
5. All files can replaced without creating new files or directories on the user's computer.
Disadvantages:
1. You will need to purchase a binary patch creation software, we list a few on this page.
2. Your application must quit and restart during the upgrade process.
Method 2: Replace all files using a single EXE
The easiest and simplest way to upgrade specific files is to build a new version of your application using Thinstall. Then this new version is shipped in its entirety to the user with the Installer enabled. The Installer will tell the old version of your software to uninstall, and then install the new version.
This method has all of the advantages of using Patch files, except that you must transmit or deliver your entire program archive to your user rather than only the parts that changed.
Method 3: Override Files in your archive with external versions
Because Thinstall's virtual filesystem is super-imposed onto the real filesystem, a file may exist at both locations at the same time. You can control which version is used on a file-by-file basis by using the Read Order Option and Extraction / Caching options. By changing the read order "Open external file first if exists", you can effectively replace files in your original archive by copying a file with the same name and path to the hard drive. For example, a file with the virtual path of %InstallPath%\mydata.dat would be replaced if you copied a file to c:\program files\myapp\mydata.dat assuming your application is stored in the directory %InstallPath%\mydata.dat.
Advantages for placing individual files:
1. Changes can be undone by simplifying deleting the version of the file on the hard drive. When you delete the hard drive version, your application will revert back to using the internal version original shipped with your application.
2. Changes can be done on-the-fly or programmatically. With patch files you need to know exactly what changes you want to make before hand. If you have a huge number of combinations of file updates, it may be unfeasible to create patch files for each scenario.
Disadvantages for replacing individual files:
The disadvantages are discussed above: lower security, more difficult to implement without problems, and high bandwidth needs.
How to replace .NET assemblies
.NET searches for assemblies in the following order:
GAC Directory
Framework directory
Application directory
Most of the files you are developing and want to replace will be located in your application directory (virtual filename = %InstallPath%\myfile.dll). To replace such a file simply copy the new version of the file to your application base directory and Thinstall will start using that version assuming you previously set the correct Read Order & Extraction/Caching options for this file.
If your application original ships with assemblies installed in the "virtual GAC", the location where you should put a replacement is a little different. Thinstall locates the GAC directory for your application under %InstallPath%\Framework_files\assembly\GAC.
Replacing .NET assemblies in the GAC Method 1: Using CopyFile
An example: replacing system.xml.dll
If you double-click on this file in your Thinstall project you should see something like this:
To update this file after your distribution ships, you need to do the following:
1. Create the directory c:\program files\myapp\Framework_files\assembly\GAC\System.Xml\1.0.5000.0__b77a5c561934e089
2. Copy your new version of System.xml.dll to this location
Replacing .NET assemblies in the GAC Method 1: Using Gacutil.exe
This method allows "proper" installation of files your virtual GAC. To use this method you must include gacutil.exe (shipped with the .NET SDK) in your project and then execute it directly by your application to install a new assembly. Because Thinstall allows multiple EXEs to reside inside your archive, you can run gacutil.exe without extracting it to disk.
Example pseudo-code:
ExecuteProcess("gacutil.exe /i mynewassembly.dll");
Note: This operation does not effect the system Global Assembly Cache (GAC), all changes occur locally to your application.