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

[Wes_Ramm1]

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.  Why does LV do this?

HELP!!??!!??

Wes Ramm

Cyth UK

[smercurio_fc]

What version of LabVIEW are you using? What version of the CLR was targeted when the assembly was created? As far as I know, LabVIEW still only supports .NET 2.0. While higher .NET versions are supposed to still work (as long as they don't use the new features in 3.5 and 4.0), my experience has been contrary.

[christian_w]

I suppose you work on two different builds of your assembly. The one you open with the reflector is not the one LabVIEW loads. If you can't find the old copy, GAC registering the assembly could solve your problem.

[Wes_Ramm1]

Duh.  Forgot the basics:

LabVIEW 2010 SP1

Building .NET 3.5

I have read that LV 2010 supports .NET fx 3.5, but can revert.  I have one dependancy that will NOT build as 2.0, but I can fix that.  

Also, LV tells me that the .NET engine is "promoting" my code to the newest version when I access the assembly via the constructor node.  Seems like this means that the 2.0 framework code is being run on the 4.0 engine?  Because I have MS Visual Studio on my machine, I am stuck with .net fx 4

[Wes_Ramm1]

@christian_w wrote:

I suppose you work on two different builds of your assembly. The one you open with the reflector is not the one LabVIEW loads. If you can't find the old copy, GAC registering the assembly could solve your problem.

---

I thought so too, but I can verify that I am looking at the same assembly when I do my compare.

W

[Wes_Ramm1]

UPDATE:

I have re(built) the entire .NET assembly to the 2.0 Framework, and I still get the same behavior.

wes

[alpha1]

Hi Wes,

We don't have any records of this issue in the past. Could you verify that this issue is caused by LabVIEW, by perhaps calling it from another C# (or other language) program? Also, are you able to try it on other versions of LabVIEW, or are you able to post the DLL (or an example/dummy DLL which experiences the same behaviour) for us to test further?

[Wes_Ramm1]

Firstly:  I found the solution.

It seems to have to do with the install of LV 2010 F2 for some reason, but ONLY on my machine.  On a second machine where we also have LV2010 F2 installed, the classes and methods were available as they should be.  

With a second .NET Test Harness, we saw the classes as they were supposed to be, and with a 3rd party .NET assembly browser we saw the classes as they were supposed to be.

However:  After a COMPLETE uninstall and reinstall of LV on my machine, the classes are visible as they should be.

Strange, but true.

W

[alpha1]

Hi Wes,

Glad to hear it's resolved. That is very weird indeed! On the bright side, your solution will now be in the archive and searchable. Thanks for providing the info on your steps to resolve it, and hope you have a great weekend! 🙂