Getting the version of a build from the project

[John Lokanis]

So, here is the problem:

I want to access the build version of my EXE with a post build action VI. My goal is to modify the welcome message in the installer build spec to include the build version. If that fails, I want to at least generate a file that can be included with the installer to label the build version. Ideally, I would like to place the build in a folder that incorporates the version in the name. Not sure yet how to accomplish this in an automated way, but the first thing to tackle is getting the version of the EXE.

I have come up with three ways to do this:

1. use project properties to extract this information (so far, a major PITA)

2. extract the information from the project file using XML tools. (also a PITA, just in a different way)

3. after the EXE is generated, use .net calls to read out the version information.

My question is, has anyone already solved this? Do you have a stable and elegant solution you can share? If not, do you have any other suggestions on how to do this?

For the NI guys, why is this so hard? Shouldn't this info be easy to access? Why should it be hard to make an installer that tells the use what version they are about to install?

Does anyone else have their own custom build system that does automated builds to new folders every night/week/etc? How do you do it?

thanks for any help or ideas.

-John

[Jon Kokott]

I don't use the NI build version, however,

This is what I did on my last project:

as a post build for the exe I create a file called <executablename>.exe.info

this file is encrypted with the following contents:

1. build date

2. build version

3. build author (I programatically retrieve the windows login info)

4. 32 bit CRC of the file (my companies proprietary algorithm)

5. Sha-1 hash

6. String (for all the stuff I forgot)

In the exe I decrypt the file (its just a hard coded password) and return those items. I find that the build date is far more useful than the build version, and it constantly gets out of sync anyway if you have multiple people making builds from a source repo. Additionally the exe is able to check that it has the correct version file as it can run a SHA-1 on itself since it was generated after the build.

If the encrypted file doesn't exist, the executable simply returns (unreleased.) This is good while I test on production equipment so that operators don't accidently use something I left on a tester.

Edited February 14, 2012 by Jon Kokott

[crelf]

If I need to do what you're talking about (which I do, but not very often) I usually use an ISS build script wrapper around my LabVIEW installer.

[John Lokanis]

Thanks for the ideas. I like the idea of the EXE verification. But, I am trying really hard to stick with native LV build specs and the installer. I just think we should have this kind of feature. Not sure I will be able to pull it off however. Can you modify the installer portion of the build spec from the post build action VI and have the change take effect before the installer build runs (when doing a build all)?

[mje]

I regularly put version numbers in splash screens etc, especially for things like nightly test builds where it is imperitive the tester know exactly which version they are running.

There is a vi in vi.lib that will natively return the version of an executable, there is no need to bust out the .NET. Sorry, no LabVIEW on my phone so I can't comment where it is or what it's called.

The problem of course is it requires an exe, so you can't get the number until you've built. For now I just wrap the call, and when debugging my version call returns a dummy string "IDE Version".

I agree it should be way easier to get this info so one could statically link that info into a VI.

[jgcode]

In the past I've used .NET and the VI mje describes.

I also using scripting to update a VI pre-build with the info programmatically.

I generally use the latter approach for tools but it would work in an exe, it's just I have re-use code for the exe.

I have posted a LabVIEW Project API and a build script on LAVA (sorry no link on mobile too) that you could look at as an example.

[Val Brown]

....There is a vi in vi.lib that will natively return the version of an executable, there is no need to bust out the .NET. Sorry, no LabVIEW on my phone so I can't comment where it is or what it's called...

The problem of course is it requires an exe, so you can't get the number until you've built.

I think you're thinking of vi.lib\platform\fileVersionInfo.llb\FileVersionInfo.vi

If so look at: https://decibel.ni.com/content/docs/DOC-3733

Edited February 15, 2012 by Val Brown

[mje]

I think you're thinking of vi.lib\platform\fileVersionInfo.llb\FileVersionInfo.vi

That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly.

The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.

[asbo]

Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly.

On the contrary, you completely remove a .NET dependency. This uses native Win32 API calls, so it's almost certainly faster too.

[John Lokanis]

Ok, so I think I have this working. At least the part of dynamically updating the installer message to reflect the version of the EXE we just built and are packaging. I also am updating the installer target folder to reflect the EXE version. This way you get a new folder every time you build the installer. So, no more clobbering the previous build output. Now I need to rename the EXE target folder based on the version. This will be harder since I will need to point the installer to the new folder each time. For now, this seems to work well. Let me know what you think.

Project Version Demo.zip

-John

[mje]

Very nice, John. I like it.

[John Lokanis]

Thanks. I will post an update once I get the other features added. My long term goal is an automated build system that is script driven and will let you do nightly builds, beta builds, release builds, including pushing them out to network drives for distribution. Now if only I could so silent installs on targets I would really have something!

[bmoyer]

Ok, so I think I have this working. At least the part of dynamically updating the installer message to reflect the version of the EXE we just built and are packaging. I also am updating the installer target folder to reflect the EXE version. This way you get a new folder every time you build the installer. So, no more clobbering the previous build output. Now I need to rename the EXE target folder based on the version. This will be harder since I will need to point the installer to the new folder each time. For now, this seems to work well. Let me know what you think.

Project Version Demo.zip

-John

This is a very useful ability and will hopefully be very useful for creating my installers that have less items to update for each version.

 

Word of caution:  I tried integrating this into an existing project where there are multiple exe's in the project and it took the version of the first exe in my project (which was not the one that I was building).  I haven't looked into how to resolve this issue yet but thanks for the headstart! 

[MarkCG]

That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly.

version.png

The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.

 

It does look like the OSX version of LV2012 doesn't have anything equivalent to 

"vi.libplatformfileVersionInfo.llbFileVersionInfo.vi" . Still though, I can see my app's version number under when I "Get Info" on it with Finder. There has got to be a way to get to it-- anyone any ideas? 

[Stobber]

John, any update? What you posted 2 years ago is still pretty cool.

[gmart]

Ideally, I would like to place the build in a folder that incorporates the version in the name.

 

Check the LabVIEW 2013 Upgrade Notes:

 

Creating Directory Versions in Build Specifications
In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build
version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination
path so LabVIEW automatically includes the build version in the directory path. You can include the
[VersionNumber] tag in the Destination path field on the Destinations page or the Destination
directory field on the Information page of the build specification properties dialog box.

 

Installer builder has the same functionality but uses the tag [ProductVersion].

[Stobber]

gmart, is there any documentation explaining each of the tags returned by "BuildSpec:GetTagNames"? Figuring each of these out on my own will be a real PITA.

[gmart]

@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

[Stobber]

@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

 

This attitude frustrates me endlessly.

Edited February 12, 2014 by Stobber