Add a version number to RT EXE files

[gsussman]

When working in the Windows development environment the application builder has the ability to implement a version number for the built executable. Additionally LabVIEW has the ability to querry this version number through a property node. I would like to see this feature carried over to RT systems as well. It would be very helpful in determining what particular build of the startup.rtexe file is running on the target.

[Deborah_B]

Versioning is an option when you build a component definition file (.cdf), which includes an rtexe and its dependencies. This is an option when you build your rtexe in the Real-Time Application Properties dialog box>>Component Definition. Creating this file allows you to deploy the real-time application using MAX or programmatically with the LabVIEW System Configuration API. You can choose to manually specify the version number when you build the application or LabVIEW will Auto increment the version number each time you build. The first build would be 1.0.0.0 and the next time you build it, it may be 1.0.0.1...etc.

[MHn]

I would not declare this point as completed.

.rtexe versions and cdf-versions are not the same.

If I deploy an application direct from the project, the cdf will not be touched.

I think, gsussman's intention was the same as mine, to increment the version of an real-time application (.rtexe) each time it is built.

Only with that I can be sure about the correct version of the .rtexe.

From the cdf-version only, I can not determine if the application (.rtexe) had been updated meanwhile.

[James@Work]

Obviously not "In Development" since 2015

However, versioning of RT Targets can be tracked easily when using images.

The image name/version is available from MAX and programmatically.

[MHn]

James,

I agree, image names / version and component definitions are possible solutions to handle a version on RT targets.

Anyways, in both ways you can exchange the .rtexe-File by deploying or FTP-transfer with a newer version without getting rid of it.

best regards,

Martin

[JoshuaP]

Obviously not "In Development" since 2015

You don't know that.

[Rannoch]

I would also like to see this completed.  Using the CDF file is a bit of a hack because you have to write your own custom code to extract the version from the XML file and it only works if it deployed in a specific way.  It doesn't prevent someone from deploying code from their local project and getting a different version.

[yledieu]

In my developments I have a workaround for this : I store the version number in a constant in the top-level VI of my RT application, and I use a "Pre-Build Action.vi" (see attached vi snippet) to update this constant each time i build the application.

Most often the version string is published by a network-published shared variable but it could be published by many ways.

[James@Work]

Thanks Yohann!

This solution looks like it would be a good option for many users and easy to implement/control.  Many years ago I used a diagram constant to write to a shared variable, but could forget to update the constant before a build.  This solution fixes the problem with that method by adding the automation.

Can you also share the contents diagram of the subVI to save people time trying to find the correct properties to drill down to the current Version Information (Major.Minor.Fix.Build) in the Build Specification?

Thanks again,

James

Thanks again,

James

[yledieu]

The SubVI "Get Build Specification Version.vi" is part of the "Application Control" -> "Application Builder" palette of Labview and the diagram of this VI is password protected.