Can I force an update/replacement of a file?

[wayneh]

I sometimes create multiple builds under the same version number, i.e. 1.0.2 may have several builds (with or without minor changes - I know I shouldn't but nevertheless...)

Currently my pacth lets users locate the desired directory, then uses this code:

g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", SelectedFolder);
if g_InstalledVersion then
	SessionVar.Set("%AppFolder%", SelectedFolder);
etc....

Am I correct in assuming that I can "force" and update by doing the following?
1) Remove the first two lines above (and eliminate the if statement accordingly)
2) Choose "force install" on the file properties for my exe file.

Will that replace the previous exe with the new one?

Is there a way to verify the exe and version, but ignore the MD5?
(That way I could be sure they are overwriting the proper version of the exe without worrying about the specific build!)


Thanks....

[Lorne]

Originally Posted by wayneh

I sometimes create multiple builds under the same version number, i.e. 1.0.2 may have several builds (with or without minor changes - I know I shouldn't but nevertheless...)

Yeah, sometimes it happens. I would recommend assigning an "internal" name to each version, though, just to help you keep track of things (it can be really easy to mix files up otherwise). Even just adding the date to the newer one, or a letter like "a" and "b."

Currently my pacth lets users locate the desired directory, then uses this code:

g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", SelectedFolder);
if g_InstalledVersion then
	SessionVar.Set("%AppFolder%", SelectedFolder);
etc....

That SessionVar.Set is redundant...CheckFolderVersion already assigns the path to %AppFolder% for you if the version is found (that's why you pass it %AppFolder% in fact ...you could use some session variable other name if you wanted).

Am I correct in assuming that I can "force" and update by doing the following?
1) Remove the first two lines above (and eliminate the if statement accordingly)
2) Choose "force install" on the file properties for my exe file.

Will that replace the previous exe with the new one?

You don't need to use force install. You can build a patch between two files if they're different -- they don't need to have different version numbers. You just need to differentiate based on a file that is different internally.

Is there a way to verify the exe and version, but ignore the MD5?
(That way I could be sure they are overwriting the proper version of the exe without worrying about the specific build!)

I'm not sure why you'd want to ignore the MD5. Generally speaking, if the MD5 of two files are the same, the files are the same. Files that are exactly the same don't need patching.

If your exe file hasn't changed, all you really need to do is add another key file, or select a different one, so Visual Patch can tell the difference between those two versions.

[wayneh]

Lorne -

I don't think you understood my issue about my files.

When using "VisualPatch.CheckFolderVersion", if the file on the client machine
(v1.0.0) is not identical to MY copy of v1.0.0 (which was used to create the patch), then patching does not occur.

They may have v1.0.0 (a), and I may have v1.0.0 (b), which is not indicated in the version number assigned to the actual exe.

I want to override this, but still be sure the client file is v1.0.0.

Does that explain it better?

[Lorne]

Originally Posted by wayneh

When using "VisualPatch.CheckFolderVersion", if the file on the client machine
(v1.0.0) is not identical to MY copy of v1.0.0 (which was used to create the patch), then patching does not occur.

That's correct, if VP2 doesn't know anything about the file on the client machine. Differential binary patching requires an exact match for the source file (the one to be patched) or it will fail.

You can enable "force install" to achieve this, although without differential binary patching the size of the patch file will most likely increase.

However, if you define a version that matches the one on the client machine, it will be able to patch it fine.

They may have v1.0.0 (a), and I may have v1.0.0 (b), which is not indicated in the version number assigned to the actual exe.

What you need is for v1.0.0 (a) and v1.0.0 (b) to both be defined in your patch. Then you can build a patch that will go from 1.0.0 (a) or 1.0.0 (b) to your current version.

The file version of the exe can still be used, if you want. Just mark the exe as a key file and Visual Patch will be able to identify (a) from (b) based on the MD5 signature.

I want to override this, but still be sure the client file is v1.0.0.

Yep. See above.

[wayneh]

Lorne -

I'm trying to do this without keeping a million little versions, so I doubt I'll include every single build into the patch.

That is why I basically need to do this:
1) After the user selects a folder, find the Key file (myapp.exe)
2) Get the (client) Key file version (1.0.0)
3) Compare the version to what is allowed in the patch (1.0.0, 1.0.1, etc)
4) Then force the update...

I can't use "VisualPatch.CheckFolderVersion" because it sees the difference in the builds.

What can I do?

[wayneh]

Ok, I kept digging and this is what I've come up with.

In the screen where the user selectes the app folder:

local SelectedFolder = SessionVar.Expand("%SelectedFolder%");
whfiles = File.Find(SelectedFolder, Filename, false, false, nil, nil);
if (whfiles) then
	whfilever = File.GetVersionInfo(whfiles[1]);
	if (String.CompareFileVersions(whfilever.FileVersion, "#OLDESTVERSION#")>-1) then
		if (String.CompareFileVersions(whfilever.FileVersion, "#NEWESTVERSION#")==-1) then
			g_InstalledVersion=whfilever.FileVersion;
		else
			g_InstalledVersion=nil;
		end
	end
end

if g_InstalledVersion then
	SessionVar.Set("%AppFolder%", SelectedFolder);
etc.....

Do you see any problems, particularly with the 'CompareFileVersions' statements?

[Lorne]

Originally Posted by wayneh

I'm trying to do this without keeping a million little versions, so I doubt I'll include every single build into the patch.

You have no choice if you want to use binary differencing. Visual Patch needs to build a difference file for every old version of the file you want to patch. That's just the way binary differencing works.

If you want to build a full-history patch without having to worry about all the different older versions, use the 'Force install' option. You can still check the exe file version if you want, but I'd personally just use a different file as a key file. (Make sure the exe is not a key file or Visual Patch will reject all installations with the b, c, d, e, etc. versions of that file.)

It might be worth noting that you don't have to build a single, full-history patch. You could do separate projects for these special cases if you wanted. Or do one full-history patch, that uses the 'Force install' option, and another "previous version to current version" patch. Do one of those every time you make a change (even if the version number doesn't change).

That becomes an even better option if you use TrueUpdate, since it can automate the process of choosing which patch to use, making it more advantageous to have many smaller patches instead of one big patch.

Depending on the size of the file in question, if you have a lot of releases the 'Force install' option is probably your best bet since for a full history patch the individual diffs will start to add up, and Visual Patch might end up using the whole file anyway. (Even if each diff is only 1% of the original file's compressed size, once you have 100 of them it makes more sense to just include the original file.)

[Lorne]

Originally Posted by wayneh

Do you see any problems, particularly with the 'CompareFileVersions' statements?

Nothing looks wrong at a quick glance. If you use 'Force install' and don't make the exe a key file, it should work.

[wayneh]

Are you saying not use the exe as a Key file because the built-in 'file locator methods' will not find it?

'Cause my whole solution is this:
1) Let VP look for the exe based on current folder - if not found then
2) Check Registry for key - if not found then
3) Allow User to select Folder and only look for valid versions

This way, I can keep the key file the exe and most times VP will find it ok.
Only when the unusual situation occurs (build b or c, etc) will the User locate the folder and then we'll patch based strictly on Version.

I know the patch files will be larger due to 'force install', but this way the patch is more flexible....

[Lorne]

Originally Posted by wayneh

Are you saying not use the exe as a Key file because the built-in 'file locator methods' will not find it?

'Cause my whole solution is this:
1) Let VP look for the exe based on current folder - if not found then
2) Check Registry for key - if not found then
3) Allow User to select Folder and only look for valid versions

This way, I can keep the key file the exe and most times VP will find it ok.
Only when the unusual situation occurs (build b or c, etc) will the User locate the folder and then we'll patch based strictly on Version.

You're right, that should work fine.