Best practices for editing projects

[MarkGreally]

Hi Folks.

I am looking for a bit of advise on handling my projects and installer files.

So I have a VI with many dependancies and sub VI's. I then add this to a project and then create the application and installer files when I want to deploy the program. If I discover a bug or need to make a change when it has been deployed I do the following: Delete the project, application and installer. I make the required changes to the VI then add to a new project and create the application and installer files, then re-install the program.

This is a bit time consuming. Is there a way to make changes to the VI which can then automatically update the application and installer files. 

Thanks,

Mark.

[Sam_Sharp · Accepted solution]

What?!? What you're doing sounds completely crazy to me! Don't worry though - there is a better way!! Have your files/code in a project and just re-build the executable/installer after you have updated your VIs...it will automatically use the latest VIs when you create the executable. You can set the build specification to automatically increment the build/version number.

You only need to create the project/build specifications (exe/installer) once!

If you need to keep track of different versions of the code, use some sort of source control like Subversion/Git etc.

I suggest you have a read here (and some of the related articles!) to learn about projects and build specifications in LabVIEW! http://www.ni.com/white-paper/7197/en/

[MarkGreally]

Thats great, will make like much easier. If I set the build specification to automatically increment the version number is it possible to recall older versions. Also if I use SVN should I add the project or just the actual code?

[Sam_Sharp · Accepted solution]

No, it is not possible to recall older versions - that's what you need SVN for!

Yes - you should put all of your source code files and the project file in the SVN repository (otherwise when you check-out the source code you would need to re-create the installer each time!).

It is also a good idea to archive the executable/installer against it's version number (e.g. when I build version V1.0.0.6 I put it in a folder called V1_0_0_6 or something) so I can easily go back to an older version if I need to without having re-build it from the source files (by going back to an older SVN revision). You can automate this with a 'post build' VI if you want.

[MarkGreally]

Thanks for this advice, this will help a lot. Another quick question. Its very common to see software packages in the following format: "MyProgram V1.1" or "YourProgram Version 2.3.4". If I develop a program from scratch should it be called version 1 or should it be related to the SVN revision number.

If it is V1.1 if I make any change should the next version be V1.2. I know SVN revisions can go up into the 100's so would get very confusing. Whats your thought on this??

[Sam_Sharp]

I ignore the SVN revisions completely when it comes to executable version numbers - I let LabVIEW increment the build number automatically and then manually adjust the major/minor/fix part of the version number as appropriate.

I do, however, tag my build numbers in SVN.

If my answers have helped, please feel free to Kudos them or mark them as the solution 🙂

[MarkGreally]

Thanks again Sam.

[Bob_Schor]

I do something a little different.  The Project maintains a Version Number (in the Build Specification) of the form 1.2.3.4, with the last part being called "Build".  I create a three-part "Version Constant" in my Project that I "change when appropriate" -- for example, one is currently 2.3.0.  I keep my Project in a Subversion Repository, which means that the Working Copy has a Revision Number that changes with each Commit/Update (for example, 4745.

I'm currently running LabVIEW 2014, which includes Set Build Specification Version, a function that sets the Major, Minor, Fix, and Build elements of the Version in the Build Spec within a Project.  I've incorporated this into a Pre-Build Action that populates the Major, Minor, and Fix elements from my Version Constant and uses an SVN Utility to get the Revision Number of the Working Copy (which is my Project Folder) to run the Set Build Specification Version at Build Time.

Of course, it doesn't quite work because NI, in its Wisdom, caches the Version Number before doing the "Pre-Build Action", so the Version Number gets updated for the next Build.  I've filed an "Idea Suggestion" to fix this, but in the meantime, I've added code at the end of my Pre-Build Action to abort the Build if the new Version Number differs from the Version originally in the Build Spec (obtained, naturally, with Get Build Specification Version).  This "aborted" Build does, however, set the Version Number, so when I immediately do a second Build, the proper Build Spec is used.

Incidentally, my Program uses Get Build Specification Version when it starts to display an identifier giving the Program's Name and Version Number, useful if (not when, only if) a bug/crash appears.

Bob (Famous Last Words) Schor

[Hooovahh]

Yeah I too and in the Bob type of situation where my version might be 1.2.1.283 where the Major, Minor, Bug fix are things I set manuall and increment as I see fit based on the changes from the previous build.  And the build number (283 in this case) is pulled from SVN.  This way if you are running an random EXE in the field, you can see what version it is, and know what commit in SVN the source came from so you can easily roll back to see if an issue can be reproduced.  For an added bonus in the reports that are generated, the software version is recorded.  So if you have a report with some odd values, you can see the version of source it came from easily.