Built a DLL from c# and Call Library Function Node

[marcoadf]

Hi comunity.

I've built my .dll file from my developed c# code. Now, I want to use it with Call Library Function Node. In the configure windows of call library function node I brownse to my .DLL. When I click Ok, I should be able to see the methods in there right? But nothing happens. Function Name still be the "avg_num" and everything else still unchaged.

Is there a problem with my .dll file? Or should I think in translating the C# code into c and carry on from there?Since all help docs and many other things examplificates with c code.

Thank you.

[Thomas L.]

Your method has to be declared public.

Furthermore you have to first instantiate your object through it's constructor

say you have an object

public class Car {
  private string car = "";
  public Car() {
    car = "Audi";
   }

  public string NewCar(string carType) {
    car = carType;
  }
}

then you need to place:
Connectivity -> .NET -> Constructor Node (click Browse and select your DLL)

and then
Connectivity -> .NET -> Invoke Node (there select NewCar)

[marcoadf]

So, from your reply I do not need the Call Library Function Node?

With Constructor Node and then the Invoke Node I can see the methods. I'm making changes in the .dll, by deleting it, create more methods and built the .dll again. And the invoke node sees always the same methods. I even deleted all nodes (constructor and Invoke node) and make the same steps again and still says there are no changes.

After the first browse to the dll in the first constructor node, when I create a new constructor node it is already pointed to my .dll. thus this means that it haven't change? I brownse again to the .dll file to update my changes, but still give me the same methods.

[Thomas L.]

As far as I know "Call Library Function Node" is for old-style DLLs (COM(+)). So this doesn't apply for .NET DLLs.

I ran a quick test and you were right. LabView doesn't update the methods if you change the DLL (haven't noticed this before, cause my DLLs are usually "finished"). BUT: If you restart LabView, it displays the correct data.

[marcoadf]

Thank you very much Thomas. I've got it working.

Best Regards.

[Thomas L.]

Glad to hear 🙂

Maybe NI should fix this, seems more like a bug than intent to me 🙂

[Lycangeek]

Okay, you've got the right idea, but let me summarize

1. If the DLL has a standard C interface (Win32, built with C/C++, etc), then use Call Library Node

2. If the DLL is COM/COM+/ActiveX, use the ActiveX Palette

3. If the DLL is .NET, use the .NET Palette

As to updating the list of methods - the issue has to do with a tradeoff of performance and usability. When you pick a .NET assembly, we load it in, grab the information from it and cache it. We could redo that every time you select it, but that's pretty expensive. Also, if you change the .NET assembly at all, we would need to recompile the VI just in case any method signature changed (add or remove a parameter, etc).

All this means that it is very non-trivial to support such a thing. Now, that doesn't mean we aren't looking at it, just that I beg your patience while we get all the issues worked out (you'd be surprised how many "okay, but what if the user does XYZ and then ABC?" you have to go through to avoid corruptions, crashes, and confused users 🙂 ).