TestStand™ Unable to Load LabVIEW™ VI With LabVIEW Run-Time Engine

Issue Details

Inside TestStand, I am trying to load a VI which calls a .NET assembly. The VI opens successfully in LabVIEW and is not broken. When trying to load the VI, I receive the following message in TestStand:

Unable to load VI '<VI_Name>' with the LabVIEW Run-Time Engine version 25.3 (64-bit).

The error references a log file located at C:\Users\<Username>\AppData\Local\Temp\TestStand\<LogFileName>.txt. In the log file, I see entries similar to:

mode: "VI_BROKEN";

callSite: "CheckVIRefsForMissingDependencies";

timestamp: "<YYYY-MM-DD...>";

vi: { name: "<VI_Name"; path: "<VI_Path>";}

missingRefees: [ { refType: "DNVA"; refIdent: { name: "mscorlib:4.0.0.0:neutral:<...>"; path: "mscorlib";}; }

Solution

This behavior may occur in TestStand 2024 Q4 and later because these versions use the .NET Core adapter and .NET 8 runtime. A LabVIEW VI that references .NET Framework assemblies may load correctly in LabVIEW but fail when loaded by TestStand if the referenced assembly or class is not available in .NET 8.

As an example, we will review how to resolve the issue for the mscorlib assembly and the System.IO.File class.

First, it is important to note the assembly (DLL) and class used by the VI. You will need to verify if the assembly is available and/or changed in .NET Core (8.0), since TestStand 2024 Q4+ uses .NET Core. We can see how the File Class (System.IO) has a difference in .NET 8.0 on the Microsoft Learn website [EXTERNAL LINK]: 

In this example, the Invoke Node refers to the class System.IO.File located in mscorlib.dll file. Since this is exclusive to .NET Framework, we can still use the System.IO.File class if we use its new location for .NET Core. In .NET Core, it can be found in the System.Private.CoreLib.dll file.

1. Right-click the Invoke Node. Go to Select Class >> .NET Core >> Browse. (Do not select .NET Framework)
2. Select the System.Private.CoreLib assembly.
3. Locate System.IO in the Objects list, expand it, and select File.

4. After selecting the System.IO.File class, we can select the same SetLastWriteTime method that was used earlier, since the same method is available in both the .NET Framework and .NET Core versions of the class. Make sure that this change is completed for all .NET assemblies and classes inside the VI.
5. Save the VI, load it in TestStand again, and verify that the VI loads without errors.

Additional Information

TestStand 2024 Q4 and newer versions use the .NET Core adapter. The .NET adapter now supports .NET 8 for .NET code module execution. TestStand can execute certain .NET Framework assemblies when the required APIs and dependencies are available in .NET 8.

Even if LabVIEW can open the VI and load the .NET assembly successfully, this doesn't mean that TestStand can also load the .NET assembly. This is because of the .NET Framework/Core difference. While TestStand (2024 Q4+) uses .NET Core, LabVIEW (as of 2026 Q1) uses the .NET Framework run-time. 

For more information, please refer to: .NET Framework To .NET Core TestStand Code Modules Migration FAQ.