topic Use Version Information from Build Specification in code in LabVIEW

Use Version Information from Build Specification in code

HolgerN — Thu, 26 Mar 2020 13:51:31 GMT

Hello,

I want to use the version information from the build specification in my application instead of the hard-coded string (2.0.6 in the attached image). But I have no idea how to get the data in my code.

Re: Use Version Information from Build Specification in code

billko — Thu, 26 Mar 2020 14:00:04 GMT

No matter what they say, Google is your friend. 😉

I Googled labview build revision in code and came up with a lot of good hits, and many different ways, depending on what, specifically, your need is...

Re: Use Version Information from Build Specification in code

cbutcher — Thu, 26 Mar 2020 16:37:30 GMT

In your other thread, Ulib claimed you can use "[VersionNumber]" in the path.

Does that not work for you?

At least in preview, "C:\Users\<cb>\builds\Untitled Project 1_[VersionNumber]\My Application" looks promising to me.

Re: Use Version Information from Build Specification in code

Kyle97330 — Thu, 26 Mar 2020 16:47:57 GMT

If you are building the EXE and want to use the version that LabVIEW embeds in it, you can use the GetVersionInfo .NET command (passing the path and filename of the EXE into it).

Re: Use Version Information from Build Specification in code

drjdpowell — Thu, 26 Mar 2020 19:33:04 GMT

I also use the EXE file version.

Re: Use Version Information from Build Specification in code

HolgerN — Fri, 27 Mar 2020 06:11:37 GMT

I found the attached VI in the internet. That fits my needs very well.

Re: Use Version Information from Build Specification in code

drjdpowell — Fri, 27 Mar 2020 09:34:48 GMT

I don't believe your solution will work in a built EXE. The EXE file version technique will work.

Re: Use Version Information from Build Specification in code

crossrulz — Sat, 28 Mar 2020 12:12:17 GMT

There is a "hidden gem" that can be revealed with Darren's "Hidden Gems in vi.lib" package using VIPM. This particular gem is FileVersionInfo.vi. It looks like it will do what you are asking. If you don't want to install the package, the VI is located at <LabVIEW>\vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi.

Re: Use Version Information from Build Specification in code

billko — Sat, 28 Mar 2020 15:43:37 GMT

@crossrulz wrote:

There is a "hidden gem" that can be revealed with Darren's "Hidden Gems in vi.lib" package using VIPM. This particular gem is FileVersionInfo.vi. It looks like it will do what you are asking. If you don't want to install the package, the VI is located at <LabVIEW>\vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi.

So that's where that VI resides. I've used it before and wanted to recommend it, but I couldn't remember where it came from.

Re: Use Version Information from Build Specification in code

Kevin_Price — Sat, 28 Mar 2020 16:40:12 GMT

I dug into the "hidden gem" version a little because the pure .NET version shown in msg #4 has a small flaw (arguably) that I've run into before. When both the Patch and Build values are 0 in the executable, the .NET string output truncates them away. So if you built up a version "1.0.0.0" in the build spec, the string output would be "1.0".

The "hidden gem" version appears to me to avoid this flaw as does the visible dev environment code shown in msg #6. Both seem to build up a string from the individual integers for Major,Minor,Patch,Build so there won't be any truncation. My guess is that the "hidden gem" version might support non-Windows platforms where the .NET version wouldn't.

-Kevin P

Re: Use Version Information from Build Specification in code

Yamaeda — Mon, 30 Mar 2020 08:25:10 GMT

@Kevin_Price wrote:

I dug into the "hidden gem" version a little because the pure .NET version shown in msg #4 has a small flaw (arguably) that I've run into before. When both the Patch and Build values are 0 in the executable, the .NET string output truncates them away. So if you built up a version "1.0.0.0" in the build spec, the string output would be "1.0".

The "hidden gem" version appears to me to avoid this flaw as does the visible dev environment code shown in msg #6. Both seem to build up a string from the individual integers for Major,Minor,Patch,Build so there won't be any truncation. My guess is that the "hidden gem" version might support non-Windows platforms where the .NET version wouldn't.

-Kevin P

The .net version also have properties to get Major, Minor, Patch and Compile versions indiviually so you can build the string yourself. 🙂

Re: Use Version Information from Build Specification in code

Kevin_Price — Mon, 30 Mar 2020 14:25:06 GMT

@Yamaeda wrote:

The .net version also have properties to get Major, Minor, Patch and Compile versions indiviually so you can build the string yourself. 🙂

Yeah, that's what we started doing after we got bit by the string-only query. (And this wouldn't be any *real* issue in a lot of cases, but in a regulated industry with documentation calling for software version 1.0.0.0 and software that self-reports only 1.0, well...)

I'm intrigued by the Hidden Gems version but we're pretty much Windows-only so for now, it ain't broke so I won't fix it. 😊

-Kevin P

Re: Use Version Information from Build Specification in code

alexderjuengere — Mon, 30 Mar 2020 18:12:38 GMT

so, here's another option - although, I don't know if this is the default generic conduct:

after you have compiled your .exe via the LabView Application Builder,

open the .exe file with an texteditor,

e.g. Windows Editor,

look at the end of the file,

voila: