Pre/Post Build in application builder.

[wiebe@CARYA]

---

@GerdW wrote:

The PreBuild action is a little bit limited because the AppBuilder internally caches all VI before calling the PreBuild VI, so you cannot change them in this step anymore…

---

But that is what I've been doing (successfully). I'm sure I use a prebuild VI that modifies a VI so classes are included in the compile. I'll have to investigate.

[GerdW]

Hi wiebe,

---

wiebe@CARYA wrote:

---

@GerdW wrote:

The PreBuild action is a little bit limited because the AppBuilder internally caches all VI before calling the PreBuild VI, so you cannot change them in this step anymore…

---

But that is what I've been doing (successfully). I'm sure I use a prebuild VI that modifies a VI so classes are included in the compile. I'll have to investigate.

---

This is what I have remembered: the PreBuild VI is called after the AppBuilder caches the VI hierarchy. But then this behaviour might have changed with the latest LabVIEW versions, my information dates from LV2011…

[Yamaeda]

---

wiebe@CARYA wrote:

Just remembered - I also have a post build action.

After building my executable, I zip all build content. The customer uses exe zips and installer zips. Sadly, the installer zips can't be created with a post build...

---

I don't know if it works, but you could probably use a system exec in post build to schedule a command line zip action in 10 secs time.

Something like schtasks /create once /tr "'c:\program files\7-zip\7z.exe' -z projectfolder" (i need to read up on the parameters)

[wiebe@CARYA]

---

@GerdW wrote:

Hi wiebe,

---

wiebe@CARYA wrote:

---

@GerdW wrote:

The PreBuild action is a little bit limited because the AppBuilder internally caches all VI before calling the PreBuild VI, so you cannot change them in this step anymore…

---

But that is what I've been doing (successfully). I'm sure I use a prebuild VI that modifies a VI so classes are included in the compile. I'll have to investigate.

---

This is what I have remembered: the PreBuild VI is called after the AppBuilder caches the VI hierarchy. But then this behaviour might have changed with the latest LabVIEW versions, my information dates from LV2011…

---

I've been doing this in 2013:

There's a small chance that it 'lags behind' one iteration, and I didn't notice. The VI is saved, but might not be used during the current cycle. I'd think I would have noticed, but that's no guarentee.

[wiebe@CARYA]

---

@Yamaeda wrote:

---

wiebe@CARYA wrote:

Just remembered - I also have a post build action.

After building my executable, I zip all build content. The customer uses exe zips and installer zips. Sadly, the installer zips can't be created with a post build...

---

I don't know if it works, but you could probably use a system exec in post build to schedule a command line zip action in 10 secs time.

Something like schtasks /create once /tr "'c:\program files\7-zip\7z.exe' -z projectfolder" (i need to read up on the parameters)

---

Like... Schedule a zip of the installer when the exe is compiled?

Tricky, but that might work.

The zipping should be delayed, so the installer can finish... No problem, I'm sure schtask can do that.

[Hooovahh]

Lets say you make a build of an EXE, and then run it.  Then you realize there was a bug so you go back to the VI, edit the VI, then rebuild it.  But if you forgot to close the EXE the build will fails since one of the first things the build does is delete the build folder but can't because the EXE is running.  There are a couple of other reasons that a file might remain locked causing the build to fail.  So I have a Pre-Build action that renames the folder from <Application Name> to <Application Name - Application Version>.  If that version already exists it adds a (1) to the new folder name.

Another thing I do is on Pre-Build the dialog comes up asking what Major, Minor, Revision, and Build the EXE should be.  If the application was in source code control it pulls the commit version and sets the build version of the EXE.  Also if there is an installer in the project, the Pre Build on the application sets the installer number to the same as the EXE.

https://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028

[Bob_Schor]

I was going to post this on the end of the 2016 Post that Hooovahh referenced, which referred to a "back and forth" on this topic since I posted my 2014 Idea Exchange request to allow Pre-Build actions to modify the Version Information before (my naive interpretation of "Pre-") the Build begins (and things get cached).  However, this is probably a better place to comment.

I now do something "slightly different" that still has a (minor, potentially ignorable) drawback.  

In 2014, I was working on a LabVIEW Real-Time Project that had a half-dozen or so Build Specs.  I set them up to use a "modified-Hooovahh" approach of "Build twice to get current SVN Version incorporated into the Project".

Fast-forward a few years to another medium-sized (seems large to me, but I know my colleagues work on really LARGE)  project that doesn't involve Real-Time.  Again, I wanted an "Automated Build", but somehow was disgruntled with my "Build Twice" solution.  I played around with the Build VIs, and decided to try to create a VI that I called "Build Right" (I was thinking of calling it "Build Left", but that seemed silly).

Build Right is included in the Project (it's just a small VI).  It figures out the path to the Project File and Project Name, uses my "Naming Convention" to find the SVN Build Number, then pops up a Dialog Box with a Text Box containing the Build Specs in the Project, and an option "Build All" (which does the Obvious Thing).  The list of Build Specs and Targets are then iterated in a For Loop that sets the Build in the Project from the SVN Version, tells the User "Building Thus-and-So", and then calls the LabVIEW Build.vi.

Before I do this, I try to remind myself (hmm -- why don't I build this into "Build Right?") to Commit my Project.  Anyway, running Build Right after the Commit immediately "invalidates" the Commit (as it modifies the Version number in the Project that had just been "Committed"), leaving you with an "off-by-one" issue, one that you definitely "know about" and can choose to ignore.  Of course, while typing this response, I thought "Hmm, why not give the User the option of editing the Project File and backing off the Build number by one?  Would this leave us in an "almost-consistent" State by effectively Reverting the Project file?".  I'll have to think about this and perhaps try to implement it (Famous Last Words -- "This should be fairly simple ...")".

Bob Schor

[labmaster]

Thank you for all responses.

However, I didn't understand this discussion but pre/post build can related to the management of source code and executive files.

labmaster.

[wiebe@CARYA]

---

@labmaster wrote:

Thank you for all responses.

However, I didn't understand this discussion but pre/post build can related to the management of source code and executive files.

---

We translated "When is it useful in setting for Pre(Post) VI which the option requires to put?" to "When are Pre(Post) VIs useful", and focused on that (even more after you asked for it). Of course we got carried away...

+ Pre build actions are preformed before LV starts building an executable.

+ Post build actions are performed after LV build the executable.

Both can be used to automate actions, every time you build an executable. Pre\Post Build actions can be anything that works in the Pre\Post Build VI templates.

So yes, 100% related to building executable files, and exclusively related to that.

[Bob_Schor]

---

wiebe@CARYA wrote:

---

+ Pre build actions are preformed before LV starts building an executable.

---

No!  This is the reason for my Idea Exchange that (so far) has been ignored.  Pre-build Actions are performed after the Build has begun, but presumably before the files are assembled into the Executable.  In particular, certain Project values, including the Version information, are cached before the pre-Build Actions are run, so you cannot use a pre-Build Action to change the Version for the current build (it will save it in the Project for you, so the next Build will show the updated Version).  Makes me think of the Carpenter's Rule, "Measure Twice, Cut Once", which for LabVIEW Builds, is simply "Build Twice".

Bob Schor