Complete the following steps to migrate platform-specific .NET assemblies when you no longer intend to support the 32-bit architecture.

  1. Replace existing 32-bit .NET code modules with 64-bit versions in-place.
  2. Move the assemblies located in the <TestStand Public> or other non-shared search directory to the equivalent 64-bit location.

If the 64-bit version of the interface remains unchanged, TestStand sequences that depend on the code modules execute in 64-bit TestStand but no longer execute in 32-bit TestStand.

If you need to simultaneously support both architectures with a .NET code module but cannot use an AnyCPU assembly, create a 32-bit version of the assembly and a 64-bit version of the assembly and use one of the following techniques to associate the assembly with the adapter:

  • Use the $(Platform) path macro. Although the default 32-bit subdirectory for .NET projects is x86 in Microsoft Visual Studio, TestStand expands $(Platform) to win32 for the .NET Adapter just as it does for the C/C++ DLL and LabWindows/CVI Adapters.
  • Use non-shared TestStand search directories.
  • Write bitness-conditional code when the 32-bit version and the 64-bit version of a .NET code module use different interfaces.
Note If you are using TestStand 2023 Q4 or earlier, you can also register the assembly in the GAC to associate the assembly with the adapter. If you register versions of an assembly in the GAC that support the x86 (32-bit) architecture and the x64 (64-bit) architecture, the .NET Runtime Engine automatically loads the correct version of the assembly.
Note If you are using TestStand 2023 Q4 or earlier, you can use .NET remoting to call a non-matching bitness of a platform-specific assembly out-of-process.