NI Package Builder : How to specify to evaluate TestStandPublic at package installation ?

[Mathieu_R.]

Hello,

I'm playing arround with the NI Package Builder. I want to evaluate how to deploy the products for TestStand (Step types) we've developped using NIPM, and how to build a package using NIPB.

When specifying the destination of files, you can use [TestStand Public Documents] "alias". But it seems that the directory is "fixed" at build time, evaluated according to the TestStand public value of the computer that is used to build the package. If I build a package on a computer with TestStand 2019, the package is be installed in TestStand 2019 public directory, even of this specific version is not installed.

Am I missing something ? Or does this "alias" could be evaluated on target computer, i.e. when the package is installed ?

(I don't know if this term "alias" is correct, but that's the way I designate this particular folder, wich in that case, relies on the system environnent variable %TestStandPublic%)

Is a package able to setup files in a directory that relies on a system environnent variable value ? Or is it something I will have to manage with Custom Execute ? (if file move is handled by post-action, uninstall process will have to be custom also...)

Best regards,

[Dane.S]

Hi Mathieu,

Since TestStand deployments are version specific to avoid type conflicts and other issues, the behavior of NIPB is the same as the behavior of the TestStand Deployment Utility. This means that the Version of TestStand used to build will be the version deployed to on a target computer.

You cannot change the alias but if you need to deploy things to specific versioned folders you can build out the path to those folders as needed, however since there will be some manual type conflict resolution most likely it is not recommended. 

[Mathieu_R.]

Hi Dane,

Thank you for that answer.

We develop Step Types (DAQmx Steps and Modbus Steps, among others), previously build in LabVIEW 2012, using packed libraries for code distribution. TestStand is able to support some previous version of LabVIEW (N-4 if I remember). By installing LabVIEW 2012 Run-Time, our products work well with TestStand 2017.

The only type conflict we may face is the link to TestStand basic standard types. And I don't think we can consider it as a conflict, once out palette has been automatically updated, save it once, and that's fine.

In order to deploy these products, we build our own installer, using InnoSetup. It allow to check the presence of a supported TestStand version (based on environment variables), the presence of the requiered LabVIEW Run-Rime (regitery key), to install the product to the currently active TestStand version, and do some stuff for licencing purposes. Cherry on the cake, we have a small piece of code that allow a global build, aligning build increment, from packed libraries to Type Palette, supporting Sequence Files (examples) and installer. Version coherency : check 😉

We have to rebuild these product for TestStand 2019. The integration with NIPM is really intersting in terms of "marketing visibility", and ease of use, in particular regarding the dependencies (LabVIEW Run-Time, driver for DAQmx Steps for instance). But If I need to build a package for every TestStand version, when nothing changes in the files we are distributing... too bad.

Moreover, LabVIEW is now able to build packed libraries that will ( should) be supported by future versions of LabVIEW Run-Time. So theorically, I can prepare a set of files to deploy, that should be supported for every future versions of TestStand and LabVIEW... but I'll need to repack them for every version of TestStand.

Does it mean that the NIPM is not the best tool to deploy TestStand adds-ons, like Custom Step Types ?

Regards,

[Mathieu_R.]

One more thing : if TestStand deployements are version specific, why is it possible to specifiy dependencies with a version greater or equal to a version ?

Typically, if I specify a dependency to TestStand Runtime (32-bits) >= 19.0.1.49152-0+f0 for instance, I am expeting somthing that will work with future version of TestStand. And will be able to adapt the setup to the target computer configuration.

Best regards,

[Dane.S]

Normally using NIPM and NIPB you would need to create a different package for each version of TestStand you are hoping to deploy to if you are using [TestStand Public].

As for allowing the selection of greater than/equal to etc. for TestStand version that is because technically you can add a dependency to any installed package and any version of this so we don't automatically restrict you. You can also deploy to a different version of TestStand than the active version but you would have to build up the specific path yourself and not use [TestStand Public]

Another potential solution would be to have 2 package, one that installs the custom steps to a temp directory, and then a follow up package that uses custom executes to determine the active version of TestStand and move the files from the temp directory to the real directory. 

[CL_eisenwr]

---

@Dane.S wrote:

Another potential solution would be to have 2 package, one that installs the custom steps to a temp directory, and then a follow up package that uses custom executes to determine the active version of TestStand and move the files from the temp directory to the real directory. 

---

You could do both in a single package as you can have N ordered custom executes for a package. You might need to write a batch/code to do the move.