In building executables, allow Pre-Build Action to modify Version Information before Version Information is used

[Bob_Schor]

I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 2.1.3.4634 crashed", and I can figure out which source this was).  I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).

However, in order to get the correct Build to appear in my Executable, I must build twice.  The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.

Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this.  I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build.  True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?

Bob Schor

[Ajay_MV]

Is there any solution to this?  We're at 2023 and I'm still looking for a way to set version information in LabVIEW build specs and then build it.

[joerg.hampel]

The way you're phrasing it ("I'm still looking for a way to set version information in LabVIEW build specs and then build it"), there are ways to do what you're asking for.

- You can open the project manually, update the version number in the build spec properties manually, and then execute the build spec manually.

- Or, you can use the Application Builder API to execute your build spec programmatically, and leverage the AB API VIs (or VI scripting) to inject your version number programmatically right before executing the build. 

Btw, this requirement to read the correct version number from SCC at build time is actually the reason I started building our Release Automation Tools many years ago...

[Hooovahh]

For the last 8 years I've been using the tools I posted here, which basically set the values, then aborts the build and tells the user to attempt the build again.  I'm just so used to it I tell an app to build and then get confused in the cases when it does have this feature, and the dialog telling me it was canceled doesn't come up.

[GICA-VS_M]

I write the version info to a constant in the block diagram of the toplevel VI that is displayed at run-time. It work nicely and I don't have to build twice.

[wiebe@CARYA]

>I write the version info to a constant in the block diagram of the toplevel VI that is displayed at run-time.

Why?

>It work nicely and I don't have to build twice.

The version is stored in the executable. Why not read it from the exe?

Spoiler

If you're sticking to storing it in a diagram, you'd better document it very well, or nobody (incl. future you) will understand what's going on.

In this idea, the opposite is the problem. Setting the project build info in the build spec.

[GICA-VS_M]

>>I write the version info to a constant in the block diagram of the toplevel VI that is displayed at run-time.

>

>Why?

>

>>It work nicely and I don't have to build twice.

>

>The version is stored in the executable. Why not read it from the exe?

Mine is an RT application, I could not find a way to pull the version info from the "executable".

>If you're sticking to storing it in a diagram, you'd better document it very well, or nobody (incl. future you) >will understand what's going on.

Of course, especially "future me".

 

>In this idea, the opposite is the problem. Setting the project build info in the build spec.

But isn't that info already in the project?

[GICA-VS_M]

>>I write the version info to a constant in the block diagram of the toplevel VI that is displayed at run-time.

>

>Why?

>

>>It work nicely and I don't have to build twice.

>

>The version is stored in the executable. Why not read it from the exe?

Mine is an RT application, I could not find a way to pull the version info from the "executable".

>If you're sticking to storing it in a diagram, you'd better document it very well, or nobody (incl. future you) >will understand what's going on.

Of course, especially "future me".

 

>In this idea, the opposite is the problem. Setting the project build info in the build spec.

But isn't that info already in the project?

[wiebe@CARYA]

>>The version is stored in the executable. Why not read it from the exe?

>Mine is an RT application, I could not find a way to pull the version info from the "executable".

That's a good reason.

[Hooovahh]

Regarding RT version stuff.  I don't know if this is a good solution, but I have a string constant on the block diagram of a VI that has the RT version.  During the Pre or Post I have that VI called and it will make a text file next to the .rtexe that is made which will have the version number in it.  So now after the build I have a text file named version.txt which has the version in it. But I realized this file isn't part of the deploy package so on running of the rtexe it will also make a text file...although now that I'm talking about it I could probably just add the version file as part of the build, and update it and then maybe deploy would bring it along.  Not ideal but it is something I can rely on.