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

[jlgalin]

I have the same needs an issues than Bob, in my case I want to run a pre-build VI that asks for final version of the executable, the user has to confirm or enter the new version for the "application compiler" generate the executable with this version. I understand that pre-build option in the build specification allow me to run a VI to do everything including change build specification version and then create the executable/installer, but the result was the version is not updated.

Finally I have to build twice to get the correct version on the executable as other users does, so It will be a good proposal for developer team to correct/implement for new LabView versions.

[Hooovahh]

@jlgalin

As mentioned earlier a hacky solution to this is to abort the first build so you don't have to build it twice.  I even added a prompt saying something like "The build was aborted intentionally, run it again".  Still a pain for sure and this in my opinion should be a CAR not a feature but NI seems to disagree.

[Bob_Schor]

Well, in my Idea Exchange post, I think I showed that I automatically "do it twice" -- it certainly is how my current Pre-Build Action VI works.

It is interesting (to me) the position that NI seems to take.  They admit that they cache the Version information first, then enter into the Pre-Build Action, and don't seem to recognize the inconguity of calling this "feature" a Pre-Build Action.  Quite frankly, it is not clear to me why whatever is happening in the Build practice, NI couldn't check and say "Hey, did the user try to change the Version Number?  Oops, I better update my cached value to reflect this", which would completely "fix" this issue.  At least they haven't (yet) deleted this "Idea" for lack of Kudos.

Bob Schor

[Bob_Schor]

After several years of struggling with the stupid illogical behavior of a "Pre-Build Action" that doesn't take place before the build, and writing a "fix" to detect it and abort the Build, I finally noticed that I can "do the whole thing" programmatically using the Build function on the Applications Palette (I'd not used these functions before).

Here's my new "simplified" (and "working") routine:

The first routine, "Choose Build Spec", is just a Modal Dialog Box with a list of the Build Specs in the Project.  The next VI finds and returns the path to the Project File (it recursively looks "up" the directory tree for a file having .lvproj, and returns its path).  SVN Build assumes that the folder containing the Project is the name of the SVN Repository, and uses SVN and LabVIEW tools to get the Revision Number, used as the Version Build, updated uses Get/Set Build Specification Version functions.  Now that the Build Spec is updated truly before (i.e. "pre") the Build Action, use the Build function to do the Build.

When I first tested this, I worried as the seconds ticked by that I was "stuck in an endless loop", so I surrounded the Build with a "Progress" message.  At last, I can Build once ...

Bob Schor

[jlgalin]

Bob, I use a similar code like yours in the pre-build action, I need to compile twice to get an executable with the correct version. So I introduce the Build Action VI as you shown in your code but when I build the specification the build locks and I have to force the closing of labview.

[Hooovahh]

It might actually be working, without any update on the build progress it won't return until the build is done.  Of course locking up for 5 minutes could mean it really is locked up, or it could mean the build takes longer than 5 minutes to complete.

[jlgalin]

After the last solution from Bob I have been squeezing my mind again with this issue to try to find a solution to change the file version through the build specification application builder I also test this issue with the new Labview 2017 32bits but it seems nothings changes related to this issue.

I explore new ways to perform the file version change and it occurred to me to do from the command line with some tool. I found this article in stackoverflow and try several tools finding that Simple Version Resource Tool works for me.

Here is my labview code where I only change the file version and product version of the application .exe file but other parameters can be changed as described in the tool help. This code is set as Post-build action, so the application is compiled and after it a dialog box is shown to enter the version. If the version changes from the version compiled the tool is called to change the file and product version of the application .exe.

[littlesphaeroid]

This applies to any of the build action parameters, not just version.

In LV2014 is was possible to change the name of a PPL after the build (it could be part of a post-build action, useful is you want to append the version of the build to the library name). In LV2015+ this broke: any change to a PPL name after the build breaks the library. As a workaround, I thought I could change the target filename using a pre-build action. No dice. PRE-BUILD DOES NOT MEAN PRE-BUILD!

Now my test architecture, built around the requirement that plugin tests have a version number appended to the PPL name, requires elaborate workarounds or manual intervention to accomplish things that I once had entirely automated. 

[Bob_Schor]

Maybe it's time for another Comment from me.  Despite the completely illogical designation of a Pre-Build Action that doesn't really start "before the Build" so you can't use it to manipulate the "Build" part of the Version number, I wasn't really happy with my somewhat-kludgy "Build Twice to Get It Done Right Once" solution.  I discovered something most of you may already know -- you can programmatically build Executables, and thereby define your own Pre-Build Actions, like this:

This is meant for a non-RT (hence "My Computer") Executable.  The pink sub-VIs do what is expected.  This gets run from within the Project, so it has access to the Project Path and Name.  Choose Build Spec uses this to present a Drop-Down list of all the Build Specs, plus a Button called "Build All", so the VI either returns one or an array of All the Build Specs, very useful to Build the Entire Project with the SVN Build incorporated in all of the Version Numbers.  

Bob "Still Waiting ..." Schor

[Bob_Schor]

Followup -- This (logical, reasonable) Proposal has been "declined" once, already, and this is the second iteration.  I'm not too sanguine that NI will "correct" it (see the argument from Bob Preis, where he says it will break compatibilty "with older versions" (which I dispute).  However, he also says "You could automate the entire Build Process yourself".

One drawback to my "Build Twice" routine come when you have a Project with multiple Builds, and you want to "Build All".   "Build Twice" (as I implemented it) relies on erroring out the first time, so tethers you to your chair during the Build All process.  So I coded up "Build Right" which prompts the User for the Build Spec (using the Build Specs present in the Project), but includes a "Build All" button that (surprise!) Builds them All.  It first updates the Version Number for the Build Spec, then passes the Spec (and other parameters such as the Project Name and the Target) to NI's Build VI.  Forget about the "broken" Pre-Build Action -- if NI won't do it, Do It Yourself!

Bob Schor