The cause:

The problem is that the Meinberg NuGet has a dependency on version 1.2.2.1 of the class library but in your solution (that uses meinberg nuget) you're installing the 1.2.2.4 nuget of the class library.

This means your QAction will have both dll's in the dllimport attribute and DataMiner will currently load up both version 1.2.2.1 and 1.2.2.4 of that library and the data returned from meinberg will expect the DmsElementId class of 1.1.2.1 but find 1.1.2.4 which causes errors.

The solution:

To fix this, you'll need to make sure all your libraries and solutions have a dependency on the same version of class library.

More details:

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions

For normal programs during compilation it will perform something called unification where a automatically generated bindingredirect is added to a file next to the .exe. The binding redirect will say that any request at runtime to a method inside class library 1.2.2.1 should use 1.2.2.4 instead. Within DataMiner it's not possible to add that binding redirect because SLManagedScripting is a single process shared between all protocols and QActions. So any bindingredirect would impact all the protocol QActions.

Instead of unification, we use parallel loading where both versions of the assembly get loaded. This works between QActions and protocols, but as shown here it can cause strange behavior if multiple versions of the same assembly are needed in the same protocol.

We're brainstorming options to split up SLManagedScripting and protocols in general into more modular 'single' programs. That would also help fix this issue and allow us to add bindingredirects and use unification.