demess

Do you mean that LabVIEW Needs other directories to run the .NET assembly without fail other than the GAC and its own Directory? Because I have all the dlls from the .NET assembly in the same folder as the VIs and LabVIEW crashes exactly after a minute. Could it be that LabVIEW crashes as soon as it unloads the dlls? Or has it got to do with the target CLR?

The problem is solved by simple calling the dll libraries from a project VI instead of a stand alone VI. Yeah I know rookie mistake. I am able to read and write on the DDS network but Labview just crashes after running the VIs. Any pointers?

Yes I am aware of it. That was another approach but I had the problem of integrating interface IDL files into Labview. Because there are like thousands of IDL files in our current DDS. And inputting every data structs from the IDL to LabView would be counter productive because of the sheer amount of it. Is there a way of integrating IDL files into LabView? My idea was converting the data structs from the IDL files into a cluster of data in LabView.

In order to Implement LabView for our current DDS API, I tried the following:

1. Using the .Net palette in Labview to call the libraries.

2. Using the RTI DDS toolkit together with the IDL files.

Still no output but I still believe in LabView

Any ideas?

Hi Rolf,

I did not use the Call Library node instead I used the .Net palette with a property node and an invoke node. I did not use the constructor node since there are static methods in it. Yes the dll files are not classical dll files and was built by Visual Studio. Do all files from the library has to be the same version of CLR? for me to be able to call the methods from the DLL successfully.

I am working on implementing Labview to a Data Distribution Service (DDS) API  which will be later used in conjunction with TestStand. I have a few  dll files which was written in c# and managed c++.  When I tried calling the dll files in LabView, the methods seemed to be missing.

On the other hand I wrote a simple c# code and I am able to call the dlls with the respective methods. I believe it is the third party unmanaged c++ which is causing the problems. Do I need a dll wrapper for this to work?