TestStand Unable to Load LabVIEW VI Due to .NET Assembly Dependency

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 points towards a detailed log file stored at 'C:\Users\<Username>\AppData\Local\Temp\TestStand\<LogFileName>.txt. Inside this log file, I see the following issue and would like to know what this means:

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 error can appear when you are using TestStand 2024 Q4 and newer versions. This appears because the .NET assembly used in the VI isn't available and/or is changed in the .NET version used by TestStand (2024 Q4+). 

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: 

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.

• Right-click the Invoke Node. Go to Select Class >> .NET Core >> Browse. (Do not select .NET Framework)
• Select the System.Private.CoreLib assembly.
• Then, scroll the Objects list until you find System.IO. Unfold the object and select File.

• 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. Then, load the VI inside TestStand and ensure that no error messages appear.

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. You can still execute .NET Framework assemblies using .NET as long as the resources used in the .NET Framework assemblies are present 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.