FileVerInfo

[rsunde]

I have used FileVerInfo to extract the "FileVersion" and "CompileTime" to log those attributes to a file.  When a person has an issue, I can look at their log file
and determine if they have the latest update of the script.  I just did an update and when testing, it does not seem like these work as expected anymore.
In fact, when using the above "attributes", there are no values at all.  If I use "#FileVersion", I get 2012,1,0,0 - I don't know what those are at all!

In addition, the "help" for FileVerInfo doesn't even list "CompileTime" (anymore?).

Did I sleep through a change to FileVerInfo?

Is there a way to get these by some other means?

[Deana]

There have been no recent changes to FileVerInfo. The only changes related to FileVerInfo was way back in 2000A. In which FileVerInfo can now return numeric version fields, by preceding the resource string name with a '#'.

There have been the following changes to the compiler:

Code Select Expand


2000B the Compiler now sets the numeric FileVersion and ProductVersion fields to match the corresponding string fields.  The strings should be specified as a series of up to four numeric fields, delimited by periods or commas or spaces (eg, "3.01" or "5,1,2,0" or "2000 1 2".  Any missing or non-numeric fields will be converted to 0.

2005A  Compiler now sets "CompileTime" version string to time of compilation.

2008A Changed WIL DLL version strings scheme.


The #fileVersion result indicates you compiled using WinBatch 2012 A. The first value is the version number and the second value is the numeric value of the version letter. 1 = a, 2 = b, 3 = c....

[rsunde]

Interesting.  I was messing around with this a bit.  I orginally specified FileVersion as 10.0 in the "Version Info" of the compiler.
When I did this, and used FileVersion and CompileTime, it was blanks.
If I used the same compiler options and used #FileVesion, I would get 2012,1,0,0.

Just for fun, I changed the FileVersion in the "Version Info" to 10.0.0, I get both the fileVesion and the compile date.
It seems like it will give me the correct info sometimes - I have to change the version some and/or delete the EXE (i.e. not overwrite it).
Definitely more challenging than before.

[Deana]

FileVersion and #FileVersion are expected to return different values. "#FileVersion" and "#ProductVersion" are 64-bit numbers, and are returned as comma-separated strings In the form "n1,n2,n3,n4", where n1 is the most significant word and n4 is the least significant word. The other fields each return a SINGLE 32-bit number.

By default the compiler uses the following default setting for an exe:

Code Select Expand

FileVersion 1.0
ProductVersion 1.0

The results from FileVerInfo, on said compiled exe, are also expected:

Code (winbatch) Select Expand

filename = DirScript():'dummy.exe'
FV = FileVerInfo(filename, "", "FileVersion")      ; returns 1.0
PV = FileVerInfo(filename, "", "ProductVersion")   ; returns 1.0
_FV = FileVerInfo(filename, "", "#FileVersion")    ; returns 1,0,0,0
_PV = FileVerInfo(filename, "", "#ProductVersion") ; returns 1,0,0,0
CT = FileVerInfo(filename, "", "CompileTime")      ; returns YMDHMS date of when the script is compiled
Exit

I am unable to reproduce a blank compile time using the current compiler.

Keep in mind that these settings are stored in a corresponding .cmp file ( in the same directory and the same root name as the source .wbt ) .

Code Select Expand


[Main]
Type=1
Src=dummy.wbt
Targ=C:\TEMP\dummy.exe
Icon=
CmpVersion=5
[Options]
TechWebPage=
UACManifestSelection=asInvoker
UACManifestUI=false
CodeSign=1
CodeSignDetails=
RunHidden=0
LargeExtractDest=0
PreventAutoExtract=0
[Version Info]
Comments=
CompanyName=Company name
FileDescription=dummy
FileVersion=1.0
InternalName=dummy.exe
LegalCopyright=Legal Copyright
LegalTrademarks=Legal Trademarks
OriginalFilename=dummy.exe
ProductName=dummy
ProductVersion=1.0
[Other Files]
Count=0
[Extenders]
Count=0

Once you successfully recompile using the latest version of the compiler those settings should be stored in the .cmp file.

[rsunde]

I am truly befuddled.
I have attached a screen shot showing the VersionInfo that I am specifying.  You can see that I am using 10.0
I also attached a screen shot of the EXE created using that version info.  As you can see, it is 2012.1.0.0
That seems like the #FileVersion info, which is not what I want, but it IS something!
Below is the code I am using to write this info to a log file

wbtpgm   =   IntControl(1004,0,0,0,0)
wbtver   =   FileVerinfo(wbtpgm, "", "FileVersion" )
wbtdte   =   FileVerinfo(wbtpgm, "","CompileTime" )
txtmsg = "HUMVPNLOGON version info - :" : @TAB : wbtpgm : @tab : "Script version:" : @tab : wbtver : @tab : "Compile date: " : @tab : wbtdte
gosub updlog

Here is the line that I get when the EXE actually runs
HUMVPNLOGON version info - :   C:\Data\Winbatch\Projects\humvpnlogon\Version100\Connect Humana Network Drives.exe   Script version:                                                                                      Compile date:    YYYY:MM:DD:HH:MM:SS
I do get the program name.  Which is good.
But the FileVersion is not present and the compile data appears to be a placeholder!

[Deana]

Okay I think I may understand the problem you might be having. Make sure your are testing a COMPILED exe. If you attempt to run your code while in WinBatch studio running interpreted you will get back NONE. FileVerInfo expects to be passed an EXE when running interpreted, however IntControl 1004 will return the .wbt filename.

[rsunde]

The stuff I posted above is from a compiled EXE.
As I mentioned yesterday, sometimes the fileversion is "right".  I.e. it is what I specify in the compiler options.
When it is "right" I get the compile date/time, too.
But I don't always get the right fileversion.  Most often, at least on this version of the project, it is 2012.1.0.0

[Deana]

The stuff I posted above is from a compiled EXE.
As I mentioned yesterday, sometimes the fileversion is "right".  I.e. it is what I specify in the compiler options.
When it is "right" I get the compile date/time, too.
But I don't always get the right fileversion.  Most often, at least on this version of the project, it is 2012.1.0.0

I am unable to reproduce using the current version of the WinBatch+Compiler. Could you please provide the .cmp of the exe file. It should provide some details about your compiler settings.

[rsunde]

CMP file attached...

[Deana]

I tested using this cmp file and only modifying the source and target paths. I am unable to reproduce this behavior. Could you please add DebugTrace(@on,'trace.txt') to the beginning of the HUMVPNLOGON.WBT. Recompile then run the compiled EXE. This will generate a trace.txt file in the same directory as the EXE. Post that trace.txt here. 

[rsunde]

I don't think you want the full 444KB of the debug trace file, so I have pulled out what I believe is the pertinent section.

wbtpgm   =   IntControl(1004,0,0,0,0)
(1279) VALUE STRING => "C:\Data\Winbatch\Projects\humvpnlogon\Version100\Connect Humana Network Drives.exe"

wbtver   =   FileVerinfo(wbtpgm, "", "FileVersion" )
(1279) VALUE UNICODE =>                                                                                 

wbtdte   =   FileVerinfo(wbtpgm, "","CompileTime" )
(1279) VALUE UNICODE => YYYY:MM:DD:HH:MM:SS

txtmsg = "HUMVPNLOGON version info - :" : @TAB : wbtpgm : @tab : "Script version:" : @tab : wbtver : @tab : "Compile date: " : @tab : wbtdte
(1279) VALUE UNICODE => HUMVPNLOGON version info - :   C:\Data\Winbatch\Projects\humvpnlogon\Version100\Connect Humana Network Drives.exe   Script version:                                                                                      Compile date:    YYYY:MM:DD:HH:MM:SS

If you really want the whole thing I guess I could provide that.

[Deana]

No I probably don't need to whole trace log. however, I was hoping to take a look at the 'header' information that is written out to the beginning of the trace log.

[Deana]

These are (undocumented) custom strings added by the WinBatch+Compiler. These apply to a Compiled WinBatch Exe.

Code Select Expand


Compiletime   
ToolsetBuildInfo   
ToolsetCopyright   

Here is the code I have been testing with:

Code (winbatch) Select Expand


DebugTrace(@on, DirScript():"trace.txt")
WbtPgm = IntControl(1004,0,0,0,0)
if RtStatus() == 1 ;Compiled Exe
   FileVersion = FileVerinfo(WbtPgm, "", "FileVersion" )
   ProductVersion = FileVerinfo(WbtPgm, "", "ProductVersion" )
   Compiletime = FileVerinfo(WbtPgm, "", "CompileTime" )
   ToolsetBuildInfo = FileVerinfo(WbtPgm, "", "ToolsetBuildInfo" )   
   ToolsetCopyright  = FileVerinfo(WbtPgm, "", "ToolsetCopyright" ) 
   Msg = "File version: " : FileVersion : @lf : "Product version: " : ProductVersion : @lf : "CompileTime: " : CompileTime : @lf: "ToolsetBuildInfo: " : ToolsetBuildInfo : @lf :"ToolsetCopyright: " : ToolsetCopyright
   Pause( WbtPgm, Msg )
Else
   Message( WbtPgm, "Sorry this script must be compiled into an EXE")
Endif
Exit

Maybe try compiling this code and run it. then post the complete resulting trace file.

[rsunde]

I have compiled the code provided above and attached the trace.txt file.
And, of course it works right!  8)

I also checked the debugtrace file for the misbehaving script (below)
I think the parts that are relevant in the initial portion of the debug log are the same...

*** Debug Initialized ***

==============================
Tue 7/9/2013 5:38:28 PM
WinBatch 32 2012A
WIL DLL 6.12ala
C:\Data\Winbatch\Projects\humvpnlogon\Version100\Connect Humana Network Drives.exe
Windows platform: NT, version: 6.1, build: 7601 (Service Pack 1)
ErrorMode: @CANCEL
Valid Code Signature: No
UAC Manifest Settings: level="asInvoker" uiAccess="false"
UAC Elevation Level: Standard User or Disabled
==============================

From what I can tell, when I compile the program and the file version that shows up in Windows Explorer
is what I specify in the compiler file info, it works.  But when, for whatever reason, it puts the 2012.1.0.0
as the file version in Windows Explorer, that's when things go wrong.

[Deana]

I see you are currently using WinBatch+Compiler 2012A. Could you possibly provide the version you had previously been using to compile this script.

[rsunde]

Well, this particular program has been around since 2005. I know I've had the log portion in there for several years.
I usually update to the latest WB+Compiler not long after it's available.

Maybe there's something odd about this particular compiler destination folder.
Just for fun, I compiled the program to two different destination folders and both of them get the file version right. 
And, when I run the program from those folders, I get the expected output.

[Deana]

Thanks for the response. We are working on trying to reliably reproduce the issue. Is there anything special about the directory with the issue?

The developers are looking into the issue. There is some current speculation that it is some type of compile 'timing' issue. I will be sure to post back with any updates as I get them...

For now, you will need to make sure that once you compile that the FileVersion and ProductVersion you see in Windows Explorer is the correct version before distributing.

[rsunde]

I am not aware of anything special about the "problem directory".
I've just tried six more compiles to that directory.  Each time I would
vary the version string. The first two time work, the second three did not and the last one did.