Jump to content

Getting the version of a build from the project


Recommended Posts

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

  • Like 1
Link to comment

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 by Jon Kokott
Link to comment

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)?

Link to comment

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.

Link to comment

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.

Link to comment

....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 by Val Brown
Link to comment

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

  • Like 1
Link to comment

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!

Link to comment
  • 1 year later...
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.

attachicon.gifProject 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! 

Link to comment
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.

attachicon.gifversion.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? 

Link to comment
  • 10 months later...

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].

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.