When accessing a .NET assembly from LV, I cannot see Public Methods and I CAN See Internal Methods

[wesramm]

I have had some old C code ported to C#, and am expecting to call that c# via a .NET assembly that we have built.

The methods and classes visible in the Constructor node are VERY different from the methods classes that we have made public.

For instance, in the .NET constructor (or in an Invoke node for a static class), I have visibility in LV to an internal class that isn't even public.

AND, MOST of my public classes aren't visible from the .NET constructor node.

In order to verify this, I have used a 3rd party .NET assembly viewer called Reflector. I have included a screenshot of

the .NET assembly we have created when viewed both by Reflector and the .NET constructor on the LV BD.

Pic 1: Screen shot from Reflector (3rd party tool for viewing .NET assemblies) showing a PUBLIC method called R3HistoryReader. I'd expect to see this when I look at the .NET constructor in LabVIEW

Pic 2: Screen shot from LV .NET constructor when I reference the assembly showing both that my public method is not there, and an internal method is....??

Pic 3: Screen shot from Reflector again showing that the R3BinaryReader class is INTERNAL.

I have built the .NET assembly to .NET Framework 3.5. When I open it in LV (constructor node), I get a message that it has been "Automaticall Promoted" by the .NET runtime engine.. I am assuming that it updates it to F the 4.0 Framework, which is not supposed to be compatible with LV.

However, why are some Public Classes not visible in LV, and why are some Internal methods visible? I know that the assembly is structured correctly, as another .NET assembly shows the Public classes where they are supposed to be and doesn't see the internal ones. A 3rd party tool (Reflector) also shows the correct structure of the assembly with regards to the public and internal classes.

What am I doing wrong here...??

Edited February 9, 2011 by wesramm

[jzoller]

...

What am I doing wrong here...??

I haven't had time to really look into this, but here are some ideas.

Static methods are not accessed via constructor, but by selecting the method in a stand alone .NET invoke node. See the old-but-probably-still-valid http://forums.ni.com...View/m-p/631352.

There's no generics support in LV, so methods returning a List<> might not show up in the available invoke list. I'm not certain if this would affect the class itself.

I'm not sure on the internal class visibility... can you actually make a constructor node for it in LV?

Joe Z.

Edited February 9, 2011 by jzoller