Key Files Explained

[Lorne]

Key files are used by Visual Patch to positively identify one version from another. Each key file should be unique to one version -- which is to say that no file with the same name and location contains exactly the same data in any other version. It should also be a file that isn't normally modified after it's installed. (For example, an .ini file isn't a good choice, because it's expected to change after the software is installed.)

A version will be identified only if all of its key files are there and they match the orginals exactly. (The match is determined by calculating the MD5 signature of the file.)

Having a main .exe file that is different from one version to another is the perfect example of a key file. It's a file that must exist (if the .exe isn't there, the software isn't properly installed). It's usually also different from one version to the next (even if all that changes is the version number, or the text on the "Help > About" window).

[Steven Carr]

I do not have any problems with key files once i figured out the best technique for *myself*.

I gave up on the idea of using the main .EXE as there were times when i would create an update when the .EXE did not change.

So i created a file, which is basically a .INI, with the extension .REL. This file is installed into the program folder. Each version has a different release information in the .REL file.

This method is not perfect, but it does work.

Then with VP it is a matter of keeping a complete copy of the installed files for each release.

Once you have that VP will work very well for keeping your end users up to date.

[Lorne]

Technically, all of your key files don't have to be unique...for example, it isn't a bad idea to mark important, unchanging files as key files in order to help Visual Patch identify your software.

You only really need to have at least one unique key file in each version, in order for Visual Patch to be able to identify that version from the others.

Ultimately, the key files are all about finding the folder where your application is installed. In fact, their whole purpose boils down to setting the %AppFolder% session variable.

Most projects do this using the VisualPatch.CheckFolderVersion action. (You can see that action in the default script for the On Startup event.) The VisualPatch.CheckFolderVersion action uses the key file information to determine whether a folder contains a recognizable version.

Since it's ultimately all done with an action, it's possible to use a completely different method to determine the folder where your application is installed -- heck, you could even write a script that just set "%AppFolder%" to a hard-coded path if you were absolutely certain that your software was installed correctly and at the exact same place on every system. Then you wouldn't technically even need key files.

In the vast majority of cases, though, the key file system makes the process easier and more robust.

[bnkrazy]

Originally Posted by Steven Carr

..I gave up on the idea of using the main .EXE as there were times when i would create an update when the .EXE did not change.

A little late reading/replying here but I had the same situation and thought I'd share how I implemented a solution.

I have an app with a database that is updated weekly. Obviously I don't need VP to create a patch for the entire application for this task, so I went about it this way:

First, TU2 downloads an INI file with a simple structure of the current versions of the App and DB.

TU2 compares the local versions (App and DB) to see if an update is required.

The majority of the time only a DB update is needed so I use TU2 to pull down and silently install a SF7 packaged DB update and all is happy.

When an App update is req'd, TU2 then pulls down a VP2 app patch and goes about it's business of silently updating the application.

The beauty of this is the processes are mutally exclusive so I save time and bandwith while at the same time the SF7/TU2/VP2 software is so seamlessly integrated with each other the end user never notices a thing until they get a message saying their system is up to date.

[Steven Carr]

Originally Posted by bnkrazy

The beauty of this is the processes are mutally exclusive so I save time and bandwith while at the same time the SF7/TU2/VP2 software is so seamlessly integrated with each other the end user never notices a thing until they get a message saying their system is up to date.

Sounds like a winner.