NI TestStand 2024 unable to load NationalInstrument.Daqmx

[G_L_I]

Hello,

I am using TestStand to call DOTNET dll. And in my library, I am using the DAQmx library.

That works correctly with TestStand 2023, and as I updated to v2024, now I have an issue : I have the message "unable to load the Daqmx.dll" .

I tried to use an example from NI, and I have almost the same issue.

Here I show the error with one of the example from TestStand DotNET4.5 measure Voltage.

As I have to compile to get the dll, I had to pass in DOTNET framework 4.8

here are the screenshot of the project (example from NI) in order to compile it : 

If I use TestStand 2023 to call it, there is no issue :

But if I use TestStand 2024 I have this issue : 

Here, the issue is not on DAQmx.dll, but on NiLmClientDLL.dll. But I suspect the issue is the same.

I found some informations about this issue, but that was for old DAQmx version and 10 years ago. I tried to reinstall DAQmx, without success.

As we are developing new test software, and will work with (at least) the 2024 version by using specific new features, I cannot stay with 2023 one.

Does anyone has an idea how to fix this issue?

Thank you in advance!

[ShockHouse]

Likely has to do something with the .NET Core 8 transition. Copied from the release notes:

.NET Adapter — .NET Assembly Execution Support

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.

Some items and resources are no longer supported. Consult the following list for some support changes and considerations users should take note of when developing with the .NET Adapter and TestStand 2024 Q4:

• The IOConfig step type no longer works with the .NET Adapter. The device drivers are located in the .NET Framework GAC location, and .NET 8 does not support loading assemblies from the GAC.
• Creating remote objects in the TestStand .NET step using the CreateRemoteObject method is no longer supported.
• Calling into the following assemblies is no longer supported:
  • GAC assemblies
  • .NET assemblies with dependencies on GAC assemblies
  • C++/CLI assemblies
• Consider the following when working with .NET assemblies and LabVIEW:
  • .NET assemblies called by a VI are not automatically added to TestStand deployments. You must manually add these dependencies to deployments they are used in.
  • NET Framework assembly dependencies called by LabVIEW during the execution of a TestStand .NET step must be placed next to these .NET Framework assemblies to prevent runtime execution errors. These dependencies can be found in the LabVIEW installation directory.
  • Passing .NET objects between LabVIEW and TestStand is no longer supported.

[TRJ]

Hi G_L_I,

TestStand is currently in the process of moving from using .NET framework to .NET Core in different parts of the application. As part of this change, in TS 2024 Q4, we have moved the .NET adapter to support executing .NET 8 code modules. The adapter can still load and execute any assemblies targeted to .NET Framework provided:

1. The code in the assembly or it's dependencies don't use .NET APIs that have been deprecated or changed in .NET Core. Basically the .NET 8 CLR should be able execute the code module without errors.

2. The way .NET Core locates and loads dependencies has changed. It no longer supports finding and loading assemblies from the GAC.

The issue you hit is because of #2. I tested with the NI-DAQ example you have mentioned and the reason the assembly doesn't load is because it has a dependency on NiLMClientDLL.dll which is only present in the GAC. The .NET 8 runtime can't locate this assembly and hence the error.

As a workaround i tried copying said dll next to NationalInstruments.Common.dll and then it loaded fine in TestStand, without having to re-target the code to .NET 8. Moving ahead, you will want to consider building your .NET code modules targeted to .NET Core so that their dependencies are pulled in correctly and the .NET CLR can locate them (in the simplest case, the top level assembly and it's dependencies are located in the same folder).

Let me know if this helps.

Regards,

Tinu

[Scott_Richardson]

Tinu, something for the product to consider is whether TestStand can detect this case, or add some additional test to the error message to note this change as a potential cause.

GLI, if helpful, the TestStand User Manual has the following in red:

.NET Adapter — .NET Assembly Execution Support

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.

Some items and resources are no longer supported. Consult the following list for some support changes and considerations to take note of when developing with the .NET Adapter and TestStand 2024 Q4:

• The IOConfig step type no longer works with the .NET Adapter. The device drivers are located in the .NET Framework GAC location, and .NET 8 does not support loading assemblies from the GAC.
• Creating remote objects in the TestStand .NET step using the CreateRemoteObject method is no longer supported.
• Calling into the following assemblies is no longer supported:
  • GAC assemblies
  • .NET assemblies with dependencies on GAC assemblies
  • C++/CLI assemblies
• Consider the following when working with .NET assemblies and LabVIEW:
  • .NET assemblies called by a VI are not automatically added to TestStand deployments. You must manually add these dependencies to deployments they are used in.
  • NET Framework assembly dependencies called by LabVIEW during the execution of a TestStand .NET step must be placed next to these .NET Framework assemblies to prevent runtime execution errors. These dependencies can be found in the LabVIEW installation directory.
  • Passing .NET objects between LabVIEW and TestStand is no longer supported.
• Sequence Editor layout files from previous TestStand versions are no longer supported.
• Consider the following when handling TestStand objects in managed code:
  • Explicitly dispose of instances of classes implementing IDisposable.
  • Explicitly assign null to class member variables of TestStand types, like Engine, SequenceContext, and PropertyObject, when the class is no longer in use.
  • Explicitly assign null to static variables of TestStand types, like Engine, SequenceContext, and PropertyObject, before shutting the TestStand Engine down.

[TRJ]

Sure Scott, we can probably handle File Not Found exceptions from the adapter and add to the error message that users should verify if the .NET Core CLR is able to locate all the dependencies of their assembly.

[G_L_I]

Hello,

Thank you very much for your answer.

Now I know why it does not work!

But I still do not understand how to "add these dependencies to deployment".

I am beginner for the use of C# code actually.. 

[TRJ]

Hi GLI,

Here is a link on how to create a deployment of your C# .NET Core project. dotnet publish would pull in all the dependencies required by your project and create self contained output. However the command itself has various options and there could be other ways to deploy so I would suggest you also refer to related Microsoft documentation on this.

Regards,

Tinu

[G_L_I]

Hi TRJ,

Thank you for your link.

That will be very helpful for me!

Best regards