Software not found

[SteveDude]

I did one patch that contained two versions 1.0.0.0 and 1.1.0.0 and it worked fine. I then added another version 1.1.0.1. When I run the update on the local machine it was create don it works fine. On any other machine it says software not found.

I did do some tweaks to the folderpath, because the local of the file being patched is actually in a subfolder of what the registry states. Don't know why the first one works and the second doesn't...

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
	local MainKey = HKEY_LOCAL_MACHINE;
	local SubKey = SessionVar.Expand("Software\\SoftBotz\\Template Editor");
	local ValueName = "Path";
	local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
	FolderPath = FolderPath .. "\\Programs";
	g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
	if g_InstalledVersion then
		SessionVar.Set("%AppFolder%", FolderPath);
	end
end

I've tried using Message Boxes to display the paths and they do display correctly.

In the IDE the install folder is set to %AppFolder%.

I did have this problem before, but I had the %AppFolder% set to %AppFolder%\Programs. Changed it and it worked. Now same problem, but no luck.

[Lorne]

What version of Visual Patch are you using?

Originally Posted by SteveDude

I did one patch that contained two versions 1.0.0.0 and 1.1.0.0 and it worked fine. I then added another version 1.1.0.1. When I run the update on the local machine it was create don it works fine. On any other machine it says software not found.

First thing is to check the identity of the key files on those other machines. Use a tool like fsum to calculate the MD5 checksum for each version of each key file on each system, including your development system. A version will only be found if all of its key files match the key files for that version in your project.

I did do some tweaks to the folderpath, because the local of the file being patched is actually in a subfolder of what the registry states. Don't know why the first one works and the second doesn't...

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
	local MainKey = HKEY_LOCAL_MACHINE;
	local SubKey = SessionVar.Expand("Software\\SoftBotz\\Template Editor");
	local ValueName = "Path";
	local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
	FolderPath = FolderPath .. "\\Programs";
	g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
	if g_InstalledVersion then
		SessionVar.Set("%AppFolder%", FolderPath);
	end
end

I've tried using Message Boxes to display the paths and they do display correctly.

Try adding a GetLastError call at the end if g_InstalledVersion is nil.

In the IDE the install folder is set to %AppFolder%.

I did have this problem before, but I had the %AppFolder% set to %AppFolder%\Programs. Changed it and it worked. Now same problem, but no luck.

What is the actual path where your key files are installed?

[SteveDude]

What version of Visual Patch are you using?

I'm using version 3.0.1.0

First thing is to check the identity of the key files on those other machines. Use a tool like fsum to calculate the MD5 checksum for each version of each key file on each system, including your development system. A version will only be found if all of its key files match the key files for that version in your project.

Not quite sure what you mean about "ALL". The other systems will have only one of the three versions of the key files. Maybe I am using key files wrong. I have the file being updated selected as a key file in each version tab.

What is the actual path where your key files are installed?

I did as suggested and have each version on the dev machine in separate folders. On the actual machines that are being updated the the path setting could be anywhere, but the files will always be in the subpath "Programs".

I am just updating a DLL which is itself the key file. This program is a plugin to another program and the entire thing only consists of two DLL's.

[Lorne]

Originally Posted by SteveDude

Not quite sure what you mean about "ALL". The other systems will have only one of the three versions of the key files. Maybe I am using key files wrong. I have the file being updated selected as a key file in each version tab.

By "all" I mean that, the version on the user's system will only be detected if there is an exact match for each and every key file in a specific version in your project.

Key files are used to tell one version from another. This is done based on their MD5 signature and their location relative to your application folder.

There are some rules that you need to follow when designating key files:

• Each version needs at least one key file. The key file must be unique to that version -- i.e. different from the files in any other version.
• The contents of the key file must not change after it's installed. Any changes to the file -- the user edited it, the hard drive corrupted it, etc. -- will prevent a version match.

Please read pages 41 and 42 in the user's guide for a detailed explanation.

I am just updating a DLL which is itself the key file. This program is a plugin to another program and the entire thing only consists of two DLL's.

Some common causes of a version not being detected:

• inappropriate key file selection
• the files have been modified/corrupted
• the wrong path is used with VisualPatch.CheckFolderVersion
• the wrong files were used in the visual patch project (you put a version 1.2 file where you meant to put a 1.3, etc.)
• the wrong files were used in the installer
• the user has a version that was never added to the Visual Patch project (e.g. a custom build)

[SteveDude]

I read through the help file again this morning and verified all of that, bbut maybe I still just don't get it. Will a patched version change the signature. Say you have 1.0.0.0, the software was patched to 1.1.0.0 and then you run the new Patch that now has 1.1.0.1 or what happens when you patch 1.0.0.0 to 1.1.0.0, I guess that would mean the key file 1.0.0.0 no longer exists so then the patch will no longer work? Is that correct? If so then how should I treat patching when the software only consists of two DLL's one that always changes from version to version and then another one that may change as well in a future release. Possibly create some kind of dummy file that would be different for each release?

The other question is, any known problems patching files that were compressed with PECompact2.

[Lorne]

Originally Posted by SteveDude

I read through the help file again this morning and verified all of that, bbut maybe I still just don't get it. Will a patched version change the signature. Say you have 1.0.0.0, the software was patched to 1.1.0.0 and then you run the new Patch that now has 1.1.0.1 or what happens when you patch 1.0.0.0 to 1.1.0.0, I guess that would mean the key file 1.0.0.0 no longer exists so then the patch will no longer work?

Woah slow down, it's hard to tell what question you're actually asking.

When you patch a file, its contents are modified, and yes that changes its MD5 signature so that it matches the new version.

For example, say you have 3 versions of a key file.

version 1 MD5: 3ab47b8d8bc19c3defa708044729065e
version 2 MD5: e00cc7b1d25abde273bf562a0b609063
version 3 MD5: b0479e6b13009e7198684f8aa9102b79

Each of those MD5 signatures is calculated from the contents of that version of the file. If another file is exactly the same on the inside, it will generate the same MD5 number.

Let's say that you run the patch, and when it looks for the key file it finds a file with the right name, and calculates its MD5 value as e00cc7b1d25abde273bf562a0b609063. That means it matches the one from version 2. If all the other key files it expects to find for version 2 match as well, then a positive match is found: the user has version 2.

However, if the file has an MD5 value of 9a8a573bdb438f506e5f4b5ad64e04a9, that value doesn't match any of the versions the patch knows about, and so no positive match can be found: the user has some unknown, unpatchable version.

Is that correct? If so then how should I treat patching when the software only consists of two DLL's one that always changes from version to version and then another one that may change as well in a future release. Possibly create some kind of dummy file that would be different for each release?

So long as at least one of the files that you select as the key file is different on the inside than it is in all other versions, it should work fine. Assuming neither file is modified by the user, selecting one or both of the files should work equally well.

Alternatively, you could include a simple text file, containing the version number, and make that your key file. That is a valid workaround

The other question is, any known problems patching files that were compressed with PECompact2.

No known problems. The DeltaMAX engine used in Visual Patch will work with any kind of data.

Although not a problem per se, compressed files generally result in larger patches -- most compression methods hide all the similarities between the files.

[SteveDude]

Okay, so I guess it means if I have three separate versions with one key file in each version (key file being the same file in each version tab, just a progressively newer version), then it should at least find the software as long as the installed version is an exact MD5 match of one of the 3 versions.

So when you said you have to match ALL key files that meant all key files for that specific version.

So my problem is still why is it still not finding the software since it has a corresponding match in the patch. When the files are organized for the build are they cached anywhere that could possibly be causing the problem? I did do a couple of builds using the same version number, but rebuilt the patch each time. So when does Visual Patch actually generate the MD5 for it's internal use, when the file is added or when the project is built. If it is not done on build that may explain the problem.

Guess the next thing that I will try is just do a new project and try it that way, instead of just updating the old project and if the problem persists to verify with the MD5 utility you mentioned.

As far as patch size that is not a concern because we are only talking 1.01 MB after the patch was built.

[Lorne]

Originally Posted by SteveDude

Okay, so I guess it means if I have three separate versions with one key file in each version (key file being the same file in each version tab, just a progressively newer version), then it should at least find the software as long as the installed version is an exact MD5 match of one of the 3 versions.

So when you said you have to match ALL key files that meant all key files for that specific version.

Yes.

When the files are organized for the build are they cached anywhere that could possibly be causing the problem?

No, all of the file information is refreshed during the build.

The only (optional) caching in VP3 is for difference files (Publish > Settings > Optimizations) but (1) it only caches diffs and (2) the cache is indexed by MD5 value, so there should be no chance of the wrong diff being used.

I did do a couple of builds using the same version number, but rebuilt the patch each time. So when does Visual Patch actually generate the MD5 for it's internal use, when the file is added or when the project is built. If it is not done on build that may explain the problem.

The MD5 value is calculated during the build from the actual file's contents.

Guess the next thing that I will try is just do a new project and try it that way, instead of just updating the old project and if the problem persists to verify with the MD5 utility you mentioned.

You could also try adding an Application.GetLastError action immediately after the VisualPatch.CheckFolderVersion action to see if that action is failing.

To check the MD5 values you can use fsum, or use Tools > Calculate MD5 in Setup Factory.

Assuming you have the current folder detection method enabled, another test is to try copying the patch into the application folder and running it from there. If it finds the application that way, the problem isn't with the MD5 values or anything, it's in the registry or your modifications to the detection script.

Actually -- going back to your original script again, here are a couple things to try:

1. Try adding String.TrimRight(FolderPath, "\\"); right after you get the FolderPath from the Registry. (If your path in the Registry has a trailing backslash, you'll end up with double backslashes in the path, because you're adding "\\Programs" to it.)
2. If that doesn't work, try removing the FolderPath = FolderPath .. "\\Programs"; line.

[SteveDude]

Lorne,

Thanks for your help on this. I gave up for the moment and am just using a patching system I had been using for awhile.

I will play this one again in couple of days when I get some time. You gave me some good food for thought. I know this a good way to go as it worked once. Like it better than the MSI stuff when we are dealing with such a small update and my current solution requires the entire original installation cached on the users system or they are required to insert the CD the software was originally distributed on.

Won't publicy mention any names on what I use, because I actually like the installer for Vista Certified applications, just don't like the patching system.

...besides your tech support is a thousand times better and I can tell you guys actually care about your product and users.

Steve