LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Pre Build EXE and Installer Set Version

So this topic comes up relatively often so I thought I'd make a new thread showing an example of how to make it work.  The problem is developers want a way to set the version of builds programmatically.  Luckily NI added some VIs for doing this.  Too bad you can't invoke them from the Pre-Build action of a build, because that information is read before the pre-build.  Here is an idea exchange discussing it.

 

But I figured I could come with some kind of work around and I have two, and neither is perfect.  Attached is a simple project.  It contains a VI that runs reading the EXE version that it is running from once it is in an EXE.  The project has three build specifications, an EXE, and two installers.  The developer can set the Major, Minor, and Fix of the EXE, but the build version is set programmatically in the Pre-Build action.  The version of the installers will also be set to the version of the EXE.

 

Attempt to build the EXE and a dialog will appear asking to enter the build version that should be used.  This could be determined some other way but this was the easiest for the demo.  If the EXE, and the Installers are already the correct version, where the build is the same as the one specified, and the installers are the same version as the EXE, then the build goes on like normal.  But if the build you enter is not the same as the current, it will abort the current build, change the versions, and then tell the operator to attempt to build again.  This time no prompt is seen and the build will work like normal with the version you set earlier.

 

The downside to this method is you have to tell the developer to build again, I figured I could do that programmatically so I tried.  There is a constant on the BD of Prebuild Action VI.vi, and if it is set to True it will try to invoke a new build on its own.  The problem with this method is the build the user invoked is aborted and the user sees the error.  But the second build might have worked fine, but there isn't any feedback.

 

In any case this is a sorta working way of setting EXE and Installer build versions from a pre-build VI.

Message 1 of 12
(8,722 Views)

Very clever!  I didn't think of deliberately aborting the Build if it didn't "take".  I took your idea and "simplified" it a little, as follows:BS PreBuild Action.png

Message 2 of 12
(8,702 Views)

@Bob_Schor wrote:

I took your idea and "simplified" it a little


Some may want the simplified version I understand.  But for me I wanted a more robust VI, one that would work if a project had multiple build specifications of applications, or multiple installers.  Some developers may have two applications one that is normal, and another with debugging turned on and I wanted the versioning to work consistently there by grabbing the newest version and using it.  And in all my cases, if there is an installer it should be the same version as the EXE.

 

As for the getting around the error I think if I had enought time I could dig into the NI VIs to get rid of the error and show the progress of the new build.  The whole build process is a bunch of VIs, that augment the right click menus in the project so the source is there it is just taking time to understand it.

0 Kudos
Message 3 of 12
(8,662 Views)

Bear with me, I've got LV 2012 on my machine right now, so I don't have that Set Build Specification Version vi handy. However, if you poke around enough on the LAVA forums, you can find the original hack using the Set Tag project method. Based on the behavior of the NI VI, I'm pretty sure it's doing the same thing.

 

Anyway, if you pass in a path to that subVI when using it in a Pre-Build action, I think it opens a new instance of the project and modifies that. But what you want it to modify the instance already in memory. It looks like Set Build Specification Version supports either using a path as an input or a project refnum. Did you try finding the current project refnum (that little For Loop at the beginning) and passing that into the NI VI? I suspect that would work, but if not, I went ahead and included my whole VI, which I can confirm works (in 2012, at least!)

Untitled.png

0 Kudos
Message 4 of 12
(8,176 Views)

 

I've tried the following methods in LV2015.  All of these update the version number after the build, the exe gets the previous version number:

  • The method Cantankerous posted
  • reference based vi for "Get/Set Build Specification Version.vi" using that Cantakerous posted to search for Project Reference
  • reference based vi for "Get/Set Build Specification Version.vi" using the VI server based Open Project method to get the Project Reference.  This is shown in the help for "Set Build Specification Version.vi"

Since none of these methods work the way we need, I can only assume that the version number must be read and stored before the Pre Build VI gets called.  I don't think there's any way around it other than aborting and restarting the build.  This works but is really kludgey

 

Anyone else been successful in getting this to work to increment the version number before the build?

 

 

0 Kudos
Message 5 of 12
(8,121 Views)

@immercd1 wrote:

 

 

Anyone else been successful in getting this to work to increment the version number before the build? 


As I mentioned in the first post there is a constant in one of the VIs that will abort the build, then reinvoke the build with the new settings.  This method works but has no visual feedback of the build process.  At the moment it is a trade off.  Do you ask the developer to perform a build again and get the progress, or do you invoke the build programatically but get none?  These are the only options I know of right now.  I've been using the method that tells the developer to rebuild and it works just fine.  Not ideal for sure but it works.

0 Kudos
Message 6 of 12
(8,109 Views)

@Hooovahh wrote:

As I mentioned in the first post there is a constant in one of the VIs that will abort the build, then reinvoke the build with the new settings.  This method works but has no visual feedback of the build process.  At the moment it is a trade off.  Do you ask the developer to perform a build again and get the progress, or do you invoke the build programatically but get none?  These are the only options I know of right now.  I've been using the method that tells the developer to rebuild and it works just fine.  Not ideal for sure but it works.


My versioning schema is a little different than what you posted.  I like to set the version to Year.Month.Day.Build.  I'd like to have it automatically increment without any intervention from the user.  I've currently implemented a dialog box that reports the current version number with two possible options: build with this current version number or abort and incrment the number (so that the developer can restart the build).

 

I wasn't exactly following your code for the auto-rebuild.  If you pass error cluster [True,42,Restart Build Process"] to the App Builder does this automatically restart the build?  I"m a little worried in my case to automate this of getting stuck in an infiite loop of rebuilds.

0 Kudos
Message 7 of 12
(8,101 Views)

There is a constant labeled "Automated Rebuild" in the Pre Build VI.vi.  Just change that to a True and you should be set.  The reason this doesn't result in an infinite loop of builds is because if the Temp Build Number.txt file exists it just builds like normal, and deletes that file.  So when you invoke the build the first time it will create this file, abort the current build (using the error cluster), then tell it to build again.  The second build sees that file and just builds with no errors, and deletes the temp file.  I don't prefer this solution, but it is how it works.  I couldn't figure out a way to get a progress easily of the second build that is invoked.

0 Kudos
Message 8 of 12
(8,092 Views)

Wow!  When did that appear?  I've had an "Idea" in the "Idea Exchange" to make the Pre-Build Action really be before the build, so you could do such things as figure out the Subversion Revision (Buld) number, save that as the "Build" part of the Build Spec Version, do this before (my "naive" interpretation of "Pre") the Build took place, then the Executable would have as its Build the Revision Number from Subversion.  But because NI, in its infinite wisdom, caches the Version information before processing the Pre-Build Action, it doesn't work unless you build twice (the first time sets the Build into the Build Spec, but uses the former Build Spec, so when you do it again, you have the correct Build Spec.  Go figure.)

 

I'd replied to Hooovahh's post earlier, where he suggested erroring out if the Build Spec "didn't take" (which I now do), but I never implemented his suggested "immediate programmatic rebuild" method.  From this latest post, it sounds like maybe NI included a "hook" to implement this and mitigate this problem with Pre-Build Action and the Build Spec Version.  I'll have to try it out ...

 

Bob Schor

 

P.S. -- Hooovahh -- if I've misunderstood your post and there is no fix yet, please advise.  Maybe in LabVIEW 2016?

0 Kudos
Message 9 of 12
(8,071 Views)

No Bob there is no new news on this issue that I know of.  And also nothing in 2016 that I know of to remedy this, but if there were I probably wouldn't be allowed to say anything on the subject.  The rebuild code I have isn't the result of NI trying to make a Pre-Build run before a build, but it is just the scripting code to perform a build spec programatically.  This has been in the Application Builder subpalette for several years now.

0 Kudos
Message 10 of 12
(8,028 Views)