Problem in file version testing

[XPect]

I definitely like this app

I now trying to get the maximum from it and I'm now stuck with file version testing.

My purpose is to check the presence (and the version) of each program. For this, I mainly use the file version check rather than registry keys.

The problem I got is that the checking seem to be done only on the 1st digit of the version.

With the code below:

[Test]selected=0

description.0 = File version Test

command.0 = Some command

file.0.0 = %programfiles%\Abilon\Abilon.exe?1.0.1.0

The result is the same whatever I check version 1.0.1.0 or only 1 (same result with operator ?>) It seem that the check is done only on the 1st digit only.

I use version 2.1.10.0, is this a bug or a syntax error ?

[BenjaminKalytta]

None of them I think. This could be a problem in file version resource. Please just send my your Abilon.exe so that I can test it.

Benjamin

[XPect]

Abilon to big to be posted here so I join you dirkey where I got the same problem.

Here is the script:

[Test]selected=0

description.0 = Dirkey version Test

command.0 = Some command

file.0.0 = %programfiles%\Dirkey2\dirkey.exe?>2.0.2.4018

But I think I made a mistake in the way I do the check.

The version of the instaled program is 2.0.2.4019 so comparing with 2.0.2.4018, the result is TRUE. In this case, the description should be with the cross line or normal ?

I'm a bit confused

On the tests I've done

file.0.0 = %programfiles%\Dirkey2\dirkey.exe?>2.0.2.4020

Line not crossed

file.0.0 = %programfiles%\Dirkey2\dirkey.exe?>2.0.2.4019

Line crossed

file.0.0 = %programfiles%\Dirkey2\dirkey.exe?>2.0.2.4018

Line crossed

So I don't understand why while comparing with 4019 tha line is crossed

dirkey.zip

[BenjaminKalytta]

WIHU compares yor new dirkey.exe version (in your case 2.0.2.4019) with the installed one.

file.0.0 = %programfiles%\Dirkey2\dirkey.exe?>2.0.2.4019

Will compare file version of old dirkey.exe with new dirkey.exe. So WIHU will compare if new version 2.0.2.4019 is greater than old version. Here some comparison results with > operator:

Old         New         Result
2.0.2.4018  2.0.2.4019  TRUE
2.0.2.4019  2.0.2.4019  FALSE
2.0.2.4019  2.0.2.4020  TRUE
2.0.2.4020  2.0.2.4019  FALSE

This mean, if versions of both files are same, this item will be striked out. Only if specified version is greater this item will be installed (will not be striked out)

It's only an interpretation thing.

Benjamin

[XPect]

That's what I was thinking, I've misunderstud the logic beyong.

I will change my settings to reflect this.

Thanks again for your help.

PS: any chance to have some day the impossibility to check an item if the existing version is the same or newer ?

See that after your studdies...

[XPect]

Sorry but I got another question related to the subject

with this example

description.2  = Dirkey 2.0a

command.2=*

file.2.0 = %ProgramFiles%\Dirkey2\Dirkey.exe?>2.0.2.4019

description.2.1 = Test

command.2.1  = 02-Utils\DirKey\dirkey.msi /Q /N

The sub branch doesn't appear, any reason for this ?

[BenjaminKalytta]

Please, just try to find it out by your self next time.

You forgot to create a 2.0 sub command here.

Benjamin

[XPect]

Sorry for this on my understanding, the test was a sub command by itself

Thanks

[gbrogers]

I just started working with this great program and I can't get a few things to work like I think they should.

1 is the version checking. It works but for some programs the full version number does not show up. The 2 programs that this happens for so far is Opera and Spysweeper.

For Opera it shows version 8.0 when it should say 8.0.7401.0

For Spysweeper it shows version 4.0 when it should say 4.0.2.349

I am using this code structure in [environment]:

spysweeper.version = %programfiles%\Webroot\Spy Sweeper\Spysweeper.exe?version

Any help would be appreciated.

[XPect]

There is different "version" fields in a file. WIHU only test one of them so sometime the information you want is not available, I got this with a few apps too.

Benjamin had this in target a few month ago but it was never implemented.

I've partially solve this by testing the file presence, it's not exactly what's needed, but it work.

[BenjaminKalytta]

The problem here is as follows:

Each executable file may contain 4 fields of version information, and not all of them are filled with content:

1. There are two fields which only store an integer version of the version number (one for product version and one for file version)

2. There may be one or two "string version" fields named "ProductVersion" and "FileVersion" which may also contain data but needent be the same.

Problem is, what if integer version (which is always) present is different from "string version"?

Ok, I added ?productversion and ?fileversion to explicitely select the one which is requested.

Limitation: 1.2d for example however will be converted to 1.2.0.0 ... i.e. only integer values are allowed.

Benjamin Kalytta

Edited June 15, 2005 by BenjaminKalytta

[XPect]

Great !

I'll test that.

Thanks Benjamin

[gbrogers]

Thanks Benjamin...

Your addition works great. That is exactly what I needed.

Too bad opera reverses the number sequence with build number first... 7401.0.1 instead of 1.0.7401.

At least now I will know what build is installed.

Thanks again.