File version info

[Joe_H]

I would like to find a way to get the file version info of an exe. I have tried the file info from openG but it does not get the version info. I looked on the MS website and found the .NET function called file version info that is supposed to be under system diagnostics but when I bring up the constuctor node it does not show up . Everything else that is supposed to be in there shows up. I want this info so that I can create a generic about dialog box for my exe. If anyone knows of an easier way to do this I would appreciate any answer.

PS I used the application builder to set the version Info..

Using LV 8.0

[bartb]

Hi,

what exactly do you want to get. The version of any EXE or the version of an VI thats build? For a VI u can use VI revision...Revision history must be on, and then you can read the current revision of your VI. This can be shown on your frontpanel by opening an app reference and using the hist.revision property.  if you need more help with this. let me hear.

cheers

B

[Dynamik]

Hi Joe,

      Are you interested in obtaining the "Product Version Number" installer setting of the Application Builder?

Not that I know how, but I'd be willing to hunt through the binary and figure-out how to extract it.

... actually didn't mean to post this - having done a bit of searching through an EXE in an unsuccessful attempt to locate the Version Number.

Hmm, maybe this is stored in the Windows registry... Yup, it's buried in HKEYLOCALMACHINE and called "Display Version" but it's stored under the product key.

Message Edited by Dynamik on 05-09-2006 03:21 AM

Message Edited by Dynamik on 05-09-2006 03:33 AM

[chrisger]

hi there,

please have a look at this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=172830&query.id=5855#M172830

[Joe_H]

Thanks for all the help. Dynamik is correct I do want the version # and other things that the application builder puts in. In LV 8.0 the application builder puts the version information into the build and this is what i want not the revision history because when you do this and build an executable it is set to zero. I have found a good way to get this with .NET (figured out what i was doing wrong) and I created a nice little generic about vi that i will share with you all for anyone to use. It is not perfect and probably needs more error checking but it works fairly well.

Here is what i did to create it.

1. make sure you have the .NET framework installed.

2. Place an invoke node on block diagram and right click to select the class.

3. select system diagnostics then under that select fileversioninfo.

4. then place a property node and wire it to the output of the invoke node.

5. then select the file metrics that you want.

Here is a picture for those that do not have 8.0.

Here is the entire VI.

Again thanks for the help.

Message Edited by Jhoskins on 05-09-200609:27 AM

Message Edited by Jhoskins on 05-09-2006 09:29 AM

[Jarrod_S.]

Hi everyone,

I also came up with a method that doesn't rely on the .NET Framework. Granted, the .NET Framework makes our lives all much easier, but you might not want to assume that your target computer will have the .NET Framework version 1.1 SP1 or higher. My method uses Win32 API calls directly to access this data. This should also give you an indication of how much time and effort abstraction saves us!

Hope this helps!

[Joe_H]

5 Stars good programming and nice error handling. I wish that the examples were as nice as this then everyone could learn the correct styles really fast.

[rolfk]

---

@jarrod S. wrote:
Hi everyone,

I also came up with a method that doesn't rely on the .NET Framework. Granted, the .NET Framework makes our lives all much easier, but you might not want to assume that your target computer will have the .NET Framework version 1.1 SP1 or higher. My method uses Win32 API calls directly to access this data. This should also give you an indication of how much time and effort abstraction saves us!

Hope this helps!

---

Very nice programming! And since I figured this request will come sooner than later I converted it to 7.0 and attached it here.
I also incorporated a little fix. Some (most including all LabVIEW.exe I have tried up to 8.0.1) executables do not seem to include a \VarFileInfo\Translation version resource tree and this usually would mean that they use the default language/code page (which of course is English) so I added a default language code of 040904e4 to the StringFileInfo subkey if none was retrievable.

Rolf Kalbermatter

Message Edited by rolfk on 05-09-2006 10:00 PM

[Jarrod_S.]

Hi Rolf,

Thanks for your help with the VarFileInfo\Translation resource. I realized this was a hole in the programs functionality, and I knew a workaround, but I was never sure how valid the workaround was. Defaulting to the English language code does sound like a good idea. It definitely works for LabVIEW.exe. I never bothered implementing this since this was designed for LabVIEW-built exes, not LabVIEW itself. LabVIEW-built exes do contain the VarFileInfo\Translation resource. I also built this in LabVIEW 8, since that was the first version that allowed users to specify executable versions and other info for their applications. But it is nice as a general tool!

[rolfk]

---

@jarrod S. wrote:
Hi Rolf,

Thanks for your help with the VarFileInfo\Translation resource. I realized this was a hole in the programs functionality, and I knew a workaround, but I was never sure how valid the workaround was. Defaulting to the English language code does sound like a good idea. It definitely works for LabVIEW.exe. I never bothered implementing this since this was designed for LabVIEW-built exes, not LabVIEW itself. LabVIEW-built exes do contain the VarFileInfo\Translation resource. I also built this in LabVIEW 8, since that was the first version that allowed users to specify executable versions and other info for their applications. But it is nice as a general tool!

---

Hmm, thinking about it there is possibly one more improvement. If the default english language does not provide any string resources another possibility might be to retrieve the current language codes from the user settings and try with them too. But this sounds quite academical as I can't imagine an installer manipulating the version resource of an executable according to the currently set user language. I will have to investigate a little more what the issue is with files not containing any translation keys.

As to manipulating the version resource of LabVIEW executables I have made some code too for this in the past for earlier LabVIEW versions but found that manipulating the exe part of an executable in any way after it has been built into an application renders the executable unusable to run as there needs also to be some modifications at the end of the file to point to the start of the embedded LLB in the executable, so that was why I haven't made a tool of this yet. Glad to see that LabVIEW 8 finally has support for adding a proper version resource to the executable.

Rolf Kalbermatter