The following list describes the new features in TestStand 4.1 and other changes since TestStand 4.0.
To comply with Windows Vista restrictions on writing to the Program Files directory and to improve usability for Windows 2000/XP users who do not have permission to write to the Program Files directory, TestStand 4.1 installs some files in different locations from previous versions of TestStand. Refer to the TestStand and Windows Vista section for more information about using TestStand on Windows Vista.
The following table lists the previous directory locations in TestStand 4.0 and the new locations in TestStand 4.1. The TestStand documentation and the table refer to these directories in the following ways:
|Location in TestStand 4.0||Location in TestStand 4.1|
|<TestStand>\Cfg||<TestStand Application Data>\Cfg|
Use the <TestStand Public>\CodeTemplates, <TestStand Public>\Components, and <TestStand Public>\UserInterfaces directories in place of the corresponding User directories in TestStand 4.0 and earlier. Use the <TestStand>\CodeTemplates, <TestStand>\Components, and <TestStand>\UserInterfaces directories in place of the corresponding NI directories in TestStand 4.0 and earlier. You can use the Engine.GetTestStandPath method to find the directories programmatically.
To modify the installed code templates or components or to create new code templates or components, copy the files from the <TestStand> directory to the <TestStand Public> directory and make changes to the copies. To modify the installed user interfaces or to create new user interfaces, modify the files TestStand installs in the <TestStand Public>\UserInterfaces directory. When you modify installed files, rename the files after you modify them if you want to create a separate custom component. You do not have to rename the files after you modify them if you only want to modify the behavior of an existing component. If you do not rename the files and you use the files in a future version of TestStand, changes National Instruments makes to the component might not be compatible with the modified version of the component. Storing new and customized files in the <TestStand Public> directory ensures that new installations of the same version of TestStand do not overwrite the customizations and ensures that uninstalling TestStand does not remove the files you customize.
The AdapterSupport\CVI and AdapterSupport\LabVIEW directories were moved to the <TestStand Public> directory because TestStand requires write access to these directories for standard users.
Complete the following tasks if you are migrating from a previous TestStand version.
TestStand sequences can use the Sequence Call step type to call subsequences. The new Sequence Hierarchy window shows the relationship between sequences and subsequences. Use the Sequence Hierarchy window to inspect and navigate a complex group of sequences to more easily modify, debug, and maintain test sequences. The Sequence Hierarchy window does not provide a way to edit Sequence Call steps and does not show execution flow while running. Use the following methods to access the Sequence Hierarchy window:
TestStand 4.1 includes an additional results table for every step so you can add arbitrary pieces of data to the result list and include that data in a report or log that data to a database. In the additional results table, enter a list of expressions or specify code module parameters you want to log. When the step executes, the step evaluates each expression and adds the result and parameter values to the Locals.ResultList property. You can log any number of data items with varying types.
Use the Additional Results panel on the Properties tab of the Step Settings pane in the TestStand Sequence Editor or use the Additional Results dialog box in a TestStand User Interface to access the additional results table.
Use the Additional Results step type when you want to log data outside the context of one particular step in the sequence. Use the Additional Results edit tab in the TestStand Sequence Editor and the Additional Results dialog box in a TestStand User Interface to configure the Additional Results step.
Refer to the AdditionalResults.seq file located in the <TestStand Public>\Examples\AdditionalResults directory for an example that demonstrates how to use the additional results feature. This example adds variables, properties, expression values, and module call parameters to the result list and report.
TestStand 4.1 updates the Database Options dialog box in the following ways to support logging additional results:
TestStand 4.1 updates the default database schema in the following ways to support logging additional results:
Click the Reload NI Schemas button on the Schemas tab of the Database Options dialog box to use previous versions of the default database schemas.
Select Tools»Profile Resource Usage to launch the Resource Usage Profiler window to view and record the resources a multithreaded TestStand system uses over a period of time. The profiler records resource usage and TestStand thread synchronization operations the system performs as long as the Resource Usage Profiler window is open.
You can review the recorded data in graphs and sortable tables to identify performance bottlenecks and design flaws and to gain insight into the behavior and timing of complex multithreaded systems. You can copy the information to external applications, such as Microsoft Word or Excel.
Refer to the Comparing Resource Usage Strategies.seq file in the <TestStand Public>\Examples\ResourceUsageProfiler directory for an example of how to use the profiler. The example sequence file automatically launches the profiler and displays instructions for the example.
TestStand 4.1 runs on Windows Vista. However, built-in security settings of Windows Vista affect some typical TestStand tasks.
The User Account Control (UAC) security component in Windows Vista requires administrator privileges for some tasks, such as installing software, running certain applications, and changing system settings. If you are logged in as a standard user, Vista launches a UAC elevation prompt for prohibited tasks. You cannot resolve the UAC elevation prompts programmatically. Refer to Microsoft documentation for more information about UAC prompts.
TestStand 4.1 uses a Windows service to automatically handle most TestStand-related UAC prompts and notifications. The National Instruments TestStand Service runs with administrator privileges in the background and is responsible for tasks that require administrator privileges. The TestStand Service does not automatically handle applying settings for remote execution and applying settings and performing actions the TestStand Version Selector application requires. Performing these actions while logged on to Windows Vista as a user with standard privileges results in a UAC elevation prompt.
Authenticode signatures can help identify the publisher of a binary file and can help ensure that a binary file has not been modified since publication. Refer to Microsoft documentation for more information about Authenticode signatures.
Add an Authenticode signature to a TestStand user interface you create if you plan to allow users to download the user interface from a non-trusted public site and you want the operating system to identify your company as the publisher of the user interface. Also add an Authenticode signature to a user interface you create if the user interface requires administrator privileges to run on Windows Vista and you want the UAC elevation prompt to identify your company as the publisher of the user interface.
To verify an Authenticode signature, the requesting computer must connect to the Internet to obtain a current Certificate Revocation List (CRL). For .NET applications, the .NET Common Language Runtime (CLR) verifies Authenticode signatures for assemblies. If the computer that loads the assembly is not connected to the Internet, the CLR waits 15 seconds before timing out.
Complete the following steps to disable CRL validation in Microsoft Internet Explorer to avoid the timeout period on the computer, even if the default browser on the computer is not Internet Explorer. Using the Internet Explorer Internet Options to disable CRL validation does not expose the computer to any additional security threats.
Alternatively, you can disable CRL validation by setting the registry key value of HKCU\Software\Microsoft\Windows\CurrentVersion\ WinTrust\Trust Providers\Software Publishing\State to 0x00023e00. To enable CRL validation, set the registry key value to 0x00023c00.
When you disable CRL validation to avoid the timeout period, the CLR does not validate Authenticode-signed assemblies and does not grant the assemblies publisher evidence or publisher identity permissions, which is the same result when a timeout occurs. If the assemblies need these permissions, the computer must connect to the Internet or you must download a current CRL every 10 –15 days.
As an alternative to disabling CRL validation for the entire computer, you can work around CRL validation if an application that uses the Microsoft .NET Framework 2.0 and that has an Authenticode signature experiences the 15-second load time delay. Microsoft provides a fix you can download so you can correct this delay for .NET Framework 2.0 applications. The .NET Framework 2.0 Service Pack 1 also includes this fix. Refer to Microsoft Knowledge Base article 936707 for more information about correcting delays in .NET Framework 2.0 applications that use Authenticode signatures.
The TestStand Sequence Editor and user interface examples do not include Authenticode signatures because National Instruments distributes TestStand through trusted channels and because the TestStand Sequence Editor and user interface examples do not require administrator privileges to run on Windows Vista. Additionally, National Instruments finds the 15-second load time delay on isolated networks unacceptable and believes that you should use discretion when disabling CRL validation. Therefore, if you run the sequence editor or example user interfaces as administrator on Windows Vista, the UAC elevation prompt does not identify the sequence editor or example user interface as a National Instruments product.
When an application launches on Windows Vista, the UAC security component determines whether to grant the application administrative privileges. A user that logs into Windows Vista as a standard user can write only to specific locations on disk and in the registry. Standard user is the default login for Windows Vista.
Microsoft recommends that applications run without requiring administrator privileges. If you design applications that do not attempt to access protected areas of the operating system, all users can run the application as intended without requiring administrator privileges. You can also include manifests to specify the execution level the application requires.
If an application does not specify an execution level in its manifest, the UAC launches the application with the standard or administrator privileges of the user. With standard privileges, the system uses virtualization to redirect any read and write operations for system files and registry keys to a per-user location instead of the actual system copy of the file or registry key. Do not create applications that rely on virtualization to perform these types of administrative operations.
The default TestStand user interface application binary files include manifests that instruct the UAC to execute the application without virtualization and without requiring administrative privileges. LabVIEW 8.5 and later automatically include a default manifest in built applications. LabWindows/CVI 8.5 and later allow you to specify a manifest for built applications. When you build the application, refer to the documentation for the ADE you used for more information about how to include a manifest.
When you launch Visual Studio 2005 from TestStand, Visual Studio runs with the same privileges you used to run TestStand. If you launch TestStand, log in as a user with standard privileges, and launch Visual Studio from TestStand, you cannot execute tasks in Visual Studio that require administrator privileges.
HTBasic currently does not support Windows Vista. If you installed the HTBasic 9.0 development environment on Windows Vista, you can still perform the Edit Subroutine and Create Subroutine functions on the HTBasic Module tab in the TestStand Sequence Editor when you use a step configured to use the HTBasic Adapter. However, HTBasic code modules might not run correctly.
TestStand 4.1 includes the following other enhancements: