Typically, you can expect to update a deployed test system to fix bugs or to add more tests over the lifetime of the test system. The initial configuration of the test system determines the size of the installer and the effort involved to build the installer to update the test system.

You can create a or for a test system. Each TestStand deployment specification file (.tsd) contains the information to create a single deployment. To create multiple deployments with different contents, define one .tsd file for each deployment.

Single Deployment

If you use a single deployment that contains all the required components for the test system, when you build a patch installer, the deployment utility must analyze and create a deployable image of the entire test system to determine the changed files to include in the patch deployment. Using this technique can increase the time required to build the patch installer to update a test system.

Multiple Deployments

You can use multiple deployments to divide the parts of the test system into groups that you most likely will upgrade at the same time. For example, you can create a deployment that contains the TestStand Runtime and another deployment that contains the rest of the test system because the TestStand Runtime is a large component that does not usually change when you update a test system. One common strategy is to use one deployment for the TestStand Runtime, another deployment for TestStand framework files, such as user interfaces and process models, and a third deployment for the rest of the test system, including test sequences and code modules. You can also create product-specific deployments that include only the test sequences and code modules required to test that product, but using this technique can become complex.

Include Shared Code in a Separate Deployment

Use separate deployments for shared code to ensure that code modules execute without errors after installation and to ensure that deployments execute correctly when you uninstall shared files.

Note Because of the issues that can result from using installers you build with the TestStand Deployment Utility to deploy shared files, NI recommends that you use only LabVIEW packed project libraries to deploy shared code and avoid sharing other types of files, such as VIs, DLLs, LLBs, sequence files, and so on, among multiple deployment utility installers.

Ensuring Shared Code Executes without Errors after Installation

Updating a shared file that multiple deployments use can affect code modules in the other deployments that depend on the shared file, especially when you use LabVIEW code modules. For example, changes to the inplaceness of a subVI require that you recompile all VIs that call the subVI. Determining which deployed VIs require recompilation can be difficult because you cannot easily detect inplaceness changes or find all the callers of a VI. Additionally, removing VIs from a shared project library can affect the VIs in other deployments.

For example, consider that you deployed Caller VI and Called VI. After deployment, you make a change in the Called VI that changes memory allocation, such as changing the data wired to an indicator to a copy of the data of another indicator, and then save the Called VI. When you attempt to run the Caller VI from the test system using the LabVIEW Run-Time Engine, the VI appears broken but loads correctly in the LabVIEW development system despite including a coercion dot.

For LabVIEW code modules, build packed project libraries and enable the Callers adapt at run time to Exported VI connector pane state option on the Connector Pane State page of the Packed Library Properties dialog box in LabVIEW. If you do not use this technique and you want to change VIs in a deployed test system, you must redeploy all the VIs in the test system to prevent run-time errors when LabVIEW recompiles VIs to account for inplaceness changes.

Uninstalling One Deployment Can Affect Remaining Deployments that Use Shared Files

When multiple deployments use installers you built using the deployment utility to install the same set of shared files and you use one of the uninstallers to remove a deployment, the deployment utility uninstaller removes the shared files from the test station computer, which might affect the remaining deployments that require the shared files. You must uninstall the broken deployment and reinstall it to work around this issue.

You can use LabVIEW packed project libraries to deploy shared files because the deployment utility installer marks the packed project library as a shared file, which the operating system reference counts correctly and does not uninstall the file until you uninstall all installers that require the shared file.