Callin a mixed mode (c#,managed c++) dll in Labview

[demess]

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?

[Rolf Kalbermatter]

Just now, demess said:

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?

If the library is written and compiled as a managed .Net assembly you do not use the Call Library Node to call its methods, but the .Net palette instead. While a .Net assembly has a DLL file ending, it is not a classical DLL at all, and only the .Net CLR has any idea how to load and reference that.

[demess]

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.

[Rolf Kalbermatter]

17 minutes ago, demess said:

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.

Well not necessarily exactly the same CLR version but there has been a change somewhere between 3.5 and 4.0 of the CLR which makes this usually break. Both the calling application, here LabVIEW, and your callees need to be on the same side of this limit. LabVIEW until 2012 or so was loading by default CLR 3.5 or lower and newer LabVIEW versions load the CLR 4.0 or higher by default. If your assemblies are created for a different CLR version you either have to recompile them to use the version LabVIEW is using or you have to create a manifest file for LabVIEW to make it load a different CLR when initializing the .Net environment. The exact procedure for creating that manifest file are detailed here. Things get hairy when you have to incorperate multiple mixed mode assemblies that use CLRs from both sides of the 4.0 version limit.

 

Edited September 15, 2016 by rolfk

[smithd]

17 hours ago, demess said:

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?

Just to be sure, are you aware of the existing labview api for dds http://sine.ni.com/nips/cds/view/p/lang/en/nid/211817

It sounds like you're trying to implement something custom so I'm guessing it won't work, but it only takes a moment to double check  

[demess]

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?

[ShaunR]

41 minutes ago, demess said:

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?

I don't have much experience with IDL (like, none ) but IIRC the MIDL compiler can create C/C++ header files.

You could try running the compiler with the /h switch then use the resulting header files with the LabVIEW DLL import wizard (Tools>Import>Shared Library)

It's a long shot but may get you some of the way.

Edited September 16, 2016 by ShaunR

[bsvingen]

On 15.9.2016 at 9:49 AM, demess said:

I believe it is the third party unmanaged c++ which is causing the problems. Do I need a dll wrapper for this to work?

Years ago (7 to be exact) I found a way to call and use C++ classes in LV. And, yes, you need a dll wrapper, or at least I think that is what it's called, if you are to use some of the C++ class methods in LV. These days I am using it again, and had to look at the old code to understand it, as I am no C programmer. Probably a no brainer to a C programmer, but what you have to do is the exact same thing you have to do to call and use C++ classes in C. You have to make the classes opaque by typedef'ing them as structs (a class IS a struct), and "extern" the prototypes. Then wrap all the methods. One cool thing by this, is that the method can be used for many C++ libraries (of simple complexity at least), and the C++ class becomes just like a by-ref'ed native LV class, only with LV DLL calling in all the methods.

Maybe not a solution to your problem, but I have a working example.

[demess]

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?

[Rolf Kalbermatter]

6 hours ago, demess said:

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?

Probably something with the .Net assembly search path in combination with some badly implemented dynamic linking. .Net by default only searches in the GAC and in the directory for the current executable for any .Net assemblies. LabVIEW adds to that the directory in which the current project files is located if you run the VIs from within a project.

[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?

[Rolf Kalbermatter]

Hard to say anything conclusive without the ability to debug the libraries in source (and no I don't volunteer to do that, that would be the original developers task). Generally .Net only looks at the GAC and the current process' executable directory when trying to load assemblies. This has been done on purpose since the old way of locating DLLs all over the place in various default and not so default places has created more trouble than it actually solved.

An application can then register additional directories explicitedly for a .Net context. LabVIEW seems to maintain seperate .Net contexts per application instance and a project is an application instance in LabVIEW, isolating almost everything from any other application instance eventhough you run it in the same LabVIEW IDE process. For project application instances LabVIEW also registers the directory in which the project file resides as a. Net assembly location. This may or may not have anything to do with your issue, but from the description of your issues, it could be that one of your assemblies is trying to load some other assembly and not properly catching the exception when that fails. But this is really all guesswork without a deeper look into the actual .Net components involved.

If you can't get the original developer of the .Net component to look into this issue for you with a source code debugger, I see not a lot of chances to get this working.

Edited October 25, 2016 by rolfk