How can I set a build specificaiton's target filename and destination directory programmatically?

[Chris V]

Hi dthor,

Have you considered turning Auto Increment on for the Version Number?  I don't know if this would be an acceptable alternative.

In another vein, you could specify a post build action that would run a VI to rename the file you just built.  In addition that would give you the advantage of not overwriting past builds (because the file would have been renamed).

You might also check out this thread: http://lavag.org/topic/11673-programmatically-build-new-project-problem/  I can't vouch for the code there, but it looked like they were making some progress towards programmatically creating Build Specifications.

Have a great day,

Chris V

[Ben]

---

@Chris V wrote:

Hi dthor,

Have you considered turning Auto Increment on for the Version Number?  I don't know if this would be an acceptable alternative.

In another vein, you could specify a post build action that would run a VI to rename the file you just built.  In addition that would give you the advantage of not overwriting past builds (because the file would have been renamed).

You might also check out this thread: http://lavag.org/topic/11673-programmatically-build-new-project-problem/  I can't vouch for the code there, but it looked like they were making some progress towards programmatically creating Build Specifications.

Have a great day,

Chris V

---

Forgive me but...

Rather than loking outside NI couldn't you give R&D a nudge to expose another method on the palette?

There has to be 1000 VIs in the folder or more and only 3 of them are available for public consumption? I think it was Roy that once said "If there is something that we can do to make your life easier we want to know about it."

Ben

[James_W]

I am looking at exactly this problem from the opposite end right now - I want to produce documentation of what the Project settings are when a project is released.

(i.e. all EXEs in the build, the files included in them, the versions ... the screen setups etc and the same for the installers and Zips.

Here are the two links I have found today which I have found helpful as they have showed me they way and I believe that by combining these two you will be able to hack your build to your hearts desire (given enough play time).

1) This link below shows how to Change the file Version Info (the Tags are different in 2010 (I don't have 2011)

http://forums.ni.com/t5/LabVIEW/8-5-broke-my-Make-VI-Server-for-BuildSpecification/m-p/603757

2) The Link below shows how to automate a build from the CMD Line

http://zone.ni.com/devzone/cda/epd/p/id/5051

Combine the 2 and accempt more params from you cmd line and you could set the build version in your cmdline and probably the description too.

for a 2010 EXE some of the Tag Names are

TgtF_productName

TgtF_fileDescription

TgtF_internalName

TgtF_fileVersion.major

TgtF_fileVersion.minor

TgtF_fileVersion.patch

TgtF_fileVersion.build

Hope this Helps

James

[James_W]

Tags in 2010

Bld_localDestDir = EXE Path to build on Local Machine root (starts ..\\ instead of c:\)

Bld_buildSpecName = name you see in project for Build Spec

TgtF_targetfileName = File to build e.g Application.exe

Don't have any idea what the unique Identifier is in the project yet that prevents you overwriting an existing EXE on a system if you copy a project, rename everything and dont recreate the build spec from scratch though.

Any ides on that would be most welcom from anyone.

James

[James_W · Accepted solution]

Here is a quick cobble together to demo what I would do based on those posts I found.

I hope it works - It is untested.

(LV2010)

James

[dthor]

@ alcava.cr

That's on the right track, but those only cover building a pre-existing build spec. I'm looking to modify one.

@ Chris V

I plan on using the auto-incrementing feature for the version number. However, my goal is to take that auto-incremented version number and append it to the build's filename and the VI's title bar. That last part can't be done in a post-build VI, to my knowledge. Also, I still haven't found a property node that returns the built executable's version number, I can only find LV's version number. But that's a different topic that we shouldn't worry about here.

@ James W

Your code looks like something that might work. I'll fiddle around with it and see if it can do what I need. I doubt I would have ever found those tag names, nor figured out that I had to use the Set Tag invoke node on that ProjectItem.

[dthor]

Well, thanks to James W, I've managed to accomplish what I intended. It took some finagling, but it works. I've attached a .zip of some poorly-documented VIs that can read and write certain EXE build parameters.

Read Build Parameters:

Input: Project Path (Path), Build Spec to Edit (String), Error In

Output: Project Path Out (Path), EXE Build Properties (Strict Typedef Cluster)

This VI finds a specific build in a project and, if it's an EXE build, returns a cluster of properties.

Write Build Parametes:

Input: Project Path (Path), Build Spec to Edit (String), Save Project? (Boolean), Error In

Output: Project Path Out (Path)

This VI finds a specific build in a project and writes the parameters found in EXE Build Properties. Optionally saves the project afterwards.

Typedefs can be found in the subfolder "Controls".

[James_W]

Well done dthor,

- now all I have to do to finish off my documentation is to get the rest of the information from the build spec. Your method for arranging the data is nicer than what I had before - Like it.

[Although with the function you use at the start of the Read and Write Build Params VIs I suspect that you don't need to go through that many reference nodes to get the reference to the ProjectItem.

- If I remember one of my trials correctly, BuildSpec is a sub class of ProjectItem, so passing the build spec into the first (NI) VI should get you a reference to the BuildSpec which you can convert to more generic class ProjectItem (without having to look for it yourself) - saves on 4 property nodes and a For loop amongst other things. and makes the VI more readable...

I suppose this method doesn't guarantee your build spec is in the project though - unless you check the Build spec has a valid string in it before you run it.]

James

[James_W]

Hi dthor

Quote:

@ Chris V

I plan on using the auto-incrementing feature for the version number. However, my goal is to take that auto-incremented version number and append it to the build's filename and the VI's title bar. That last part can't be done in a post-build VI, to my knowledge. Also, I still haven't found a property node that returns the built executable's version number, I can only find LV's version number. But that's a different topic that we shouldn't worry about here.

Have a look at this VI. All of the info in here I got from a KB article a while back when trying to setup a help window with the correct VI version information.

There is no reason why you can't set the window title at runtime dependent on the build version with just 1 piece of code.

and that should be you sorted!!

James

[James_W]

I plan on using the auto-incrementing feature for the version number. However, my goal is to take that auto-incremented version number and append it to the build's filename and the VI's title bar. That last part can't be done in a post-build VI, to my knowledge. Also, I still haven't found a property node that returns the built executable's version number, I can only find LV's version number. But that's a different topic that we shouldn't worry about here.

Have a look at this VI. All of the info in here I got from a KB article a while back when trying to setup a help window with the correct VI version information.

There is no reason why you can't set the window title at runtime dependent on the build version with just 1 piece of code.

and that should be you sorted!!

James

[dthor]

Oh, FileVersionInfo.vi. That's exactly what I need. Where did you find that? Ah, ...vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

Man, I really wish NI would put all this cool stuff into the palettes. I don't like rummaging around in vi.lib to try and see if something I want already exists.

Thanks!