Unable to find software?

[NigelLacey]

Hi,

As a newcomer to patching, I am having problems with my patch finding the target software. Has anyone else had problems?.......Help!!

[AXXESS]

Hi,

Check out this post - it may be of interest to you. Proper key file choice is critical to finding your software, as well as having the location of the software written to the registry by the installer...

[Trevor Lane]

Hi,

As a newcomer to patching, I am having problems with my patch finding the target software. Has anyone else had problems?.......Help!!

I have been having the same problems. I have now had a chance to examine the log files from my clients laptops. They all say the same thing, It all worked until I updated to V2.0.1, V2.0.2 did not fix it. I have just rolled my system back to V2.0.0 in the hope it will all work again.

For your information, if it helps, all of my patches are silent and only run from the current directory. I do not use registry entries or file searches.

[Ted Sullivan]

It is extremely important that you choose your "Key Files" appropriately. Please take a minute to go through the important concepts in Chapter 1. It will make everything much clearer. I have reproduced some of the important bits below. You can get the full story from:

http://www.indigorose.com/webhelp/vp20/

Key Files
Each version of your software usually includes one or more files that are unique to that version. For instance, as new features are added, your software’s main executable might change, along with a help file and perhaps a few data files. Visual Patch refers to these "identifiable" files as key files.

Key files are used to locate and identify your software on the user’s system.

Designating a file as a key file means that you want Visual Patch to verify its existence and its MD5 signature in order to fully identify the version it belongs to. If the key file doesn’t exist, or its MD5 signature doesn’t match, Visual Patch will consider that version not found.

Each release of your software must have at least one key file, but you can specify as many as you want. It’s important to remember that every key file in a version must be found in order for that version to be identified. In other words, a user must have all of the key files from a given release installed in order for their version to "qualify." If you have four key files for a particular version and only three of them are found, the version on the user’s system won’t be considered legitimate. The same goes for a user with three key files from one version, and one from another. All the key files must match the original files from a single release absolutely.

It’s also important to remember that each key file will be verified by its MD5 signature. Care should be taken to avoid selecting key files that are likely to change for legitimate reasons once they’re installed. For example, if your software uses a database file that is constantly updated, that file wouldn’t be a good choice for a key file because its MD5 signature will change. The key files on a user’s system must all be present, and their MD5 signatures must all match the original values determined for those files at design time.

If the patch doesn’t find a valid release anywhere on the user’s system, the user won’t be allowed to update their software.

Choosing Appropriate Key Files
Key files are usually files whose contents are unique to a single version. Visual Patch requires at least one unique key file per version in order to uniquely identify that version. The file names and paths don’t need to be unique, but their contents do. In other words, you must designate at least one key file per version whose contents are different from every other version. Otherwise, the patch won’t be able to tell that version apart from the others.

Key files must also not change after being installed or patched because Visual Patch relies on their MD5 signature for validation. Files that are normally modified after they are installed (for example, .ini files) should never be designated as key files. If a key file has been changed in any way from the original file that is referenced in your project, it will prevent the version from being identified.

Each version can contain as many key files as you like. In fact, it’s a good idea to designate additional key files to help ensure a positive identification.

Tip: Good candidates for key files are executables, images, help files, PDF docs, readme files...anything that can be used to tell one release from another, but isn’t expected to change once it’s installed.

The best key files are files that change from one version to the next, such as the main executable for the software. As a matter of fact, 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 also usually different from one version to the next, even if all that changes is the version number or the text on the "Help > About" window.

Mission-Critical Files
Although at least one of the key files in a version needs to be unique to that version, they don’t all have to be. You can also use the key file feature to perform validation on mission-critical files. For example, if your software contains a really important file whose existence and integrity must be checked, making it a key file will prevent the patch from proceeding if the file has been removed or modified.

Remember: a version will be identified only if all of its key files are there and they match the originals exactly.

[NigelLacey]

Many Thanks

It is extremely important that you choose your "Key Files" appropriately. Please take a minute to go through the important concepts in Chapter 1. It will make everything much clearer. I have reproduced some of the important bits below. You can get the full story from:

http://www.indigorose.com/webhelp/vp20/

Thanks Ted,

I must try harder
I must try harder
I must try harder

Just like being back at school!

Cheers

Nigel Lacey