Constructor of .NET class not available in LV 8.20

[HJPhilippi]

Hi folks,

I've written a C# collection "TimerPrograms" that is derived from another class, which itself is derived from a generic dictionary in .NET 2.0. Using "TimerPrograms" in LabVIEW 8.0 works like a charm, I place the .NET constructor node in the diagram and chose the parameterless constructor TimerPrograms() that is listed for this class within the assembly.
Now I try to open the same VI within VMware running a LabVIEW 8.20 evaluation version (.NET runtime 2.0 installed, too) - and get a broken constructor node there. Trying to select the constructor TimerPrograms() again, I see that it is not available in the "Select .NET Constructor" dialog box for my class anymore, while the constructors of other classes are still there!

Any idea what this could be? Does LV 8.20 have known problems with generic dictionaries or so?
How could I find out why the "Select .NET Constructor" dialog box does not even list the mentioned constructor?

Any help is greatly appreciated!

Greetings,
Hans

[TCPlomp]

Hello Hans,

have you installed your own collectino (TimerPrograms) installed in the VMWare environment?

Ton

[HJPhilippi]

---

have you installed your own collectino (TimerPrograms) installed in the VMWare environment?

---

Hi Ton,

sure, I've put all my .NET assemblies (DLLs) in the same directory like the LabVIEW VIs, on the host system as on the test environment for LV 8.20 within VMware. As I've said before: Other classes work, it's only the generic "TimerPrograms" dictionary that doesn't - obviously because of its constructor that isn't "found"...

Hans

[Lycangeek]

I'm not aware of anything we did that would cause this, but obviously something has changed.

Can you post up a simple assembly and VI that shows this problem? I'll take a look at it if you can.

[HJPhilippi]

Hi Brian,

many thanks for your offer to have a look at the DLLs, your help is greatly appreciated! Attached you'll find a small ZIP archive with the following contents:

- BCON.Interface.dll = .NET contract assembly with interface definitions
- BCON.Project.Configuration.dll = .NET assembly with class implementations
- Create TimerPrograms Instance.vi = simple example VI with TimerPrograms() constructor
- Missing TimerPrograms() constructor LV8.20.png = screenshot created under LV 8.20

Some brief explanations: my generic class ConfigurationCollection<T> (within the BCON.Project.Configuration namespace) is derived from a generic Dictionary<string, T>, and the more specialized collection TimerPrograms (namespace BCON.Project.Configuration.Timer) itself derived from ConfigurationCollection<ITimerProgram>.
Therefore TimerPrograms is simply a generic dictionary for TimerProgram objects with some added attributes/methods.

With LV 8.0 on my host system, the example VI works fine. Under LV 8.20 within VMware, the generic collections like TimerPrograms do not list their constructors any longer (while the simple objects like e.g. TimerProgram do), therefore the LV constructor node is broken. I assume it's a missing/not found (.NET 2.0 runtime?) assembly, but unfortunately the constructor dialog does not show any hint if there's a problem reading the interfaces or resolving further references etc.

Hopefully you can find the reason why it doesn't work.

Thanks again + greets,
Hans

[Lycangeek]

Yeah, I was afraid of this...it isn't going to work as is in 8.20...in truth, it may not work in 8.0 either...you may just not have hit it (or you might never...all depends on what you're doing).

Short Answer: You'll need to hide your generics behind an interface.

Long Answer: The problem comes into the size that type names can reach when you use .NET generics. For example, the killer part for you here is the following base class name of TimerPrograms:

System.Collections.Generic.Dictionary`2[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[BCON.Interface.Project.Configuration.Timer.ITimerProgram, BCON.Interface, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

This name exceeds 255 characters. Why does that matter? Well, here we get into some LabVIEW issues...

Due to history, need and optimization for things such as the Realtime platform, the "type manager" of the internals of LabVIEW restrict some strings to 255 in size. This manager is the thing that handles VI Server, ActiveX, .NET, etc. Before .NET generics, this wasn't a problem because you never ran into a typename that exceeded the size and the various optimizations using 255 limits worked like a champ. Since .NET support for LV is built on this infrastructure, there are code paths where the type name would get truncated and thus be invalid when we passed it back to .NET. In 8.20, you're hitting one of those code paths.

I'm working on scrubbing these paths to get it to work, but I can't say when you'll have a version of LV in your hands with that done. In the meantime, the best solution is to create an interface for TimerPrograms and the other items you plan to use that don't publicly expose any generic types (at least ones greater than 255 characters).

Message Edited by Lycangeek on 11-28-2006 03:51 PM

[HJPhilippi]

Hi Brian,

thanks for the profound explanation and insider info regarding the generics' problem. Actually, the whole thing began even earlier when I had to realize it's tedious (if not impossible...) to use LabVIEW with dynamic .NET instantiation (object factory) like I do in C#, and switched back to directly referenced assemblies and constructor nodes. But that's a different story.

At least now I'm sure that I've not made any obvious mistakes, and I can elaborate on the workaround. Would be nice if the issue could be targeted with a forthcoming LV maintenance release, though!

Greetings,

Hans

[Lycangeek]

I'm confused about the comment regarding dynamic constructions. I'm assuming you mean a factory method that returns a System.Object...does the cast node in the .NET palette not work for you?

[HJPhilippi]

I'm using a small, yet flexible open source object factory from Ralf Westphal in my C# clients: http://tinyurl.com/yl4g42

Trying the same in LabVIEW, I got problems with creating the object instances of the generic dictionaries, what made me use the directly referenced constructors again. This worked (under LV 8.0), and I thought the dynamic object creation itself was the problem - but obviously it is not, having your latest info.
The cast node works like desired, no problems with it.

Greetings,
Hans

[Dave_B]

I am having a similar sort of problem.  In 8.0 I have a .vi that uses a .NET assembly with a class that communicates with the SW in my HW device.  This works just fine, I can 'see' and use all of the methods and properties available in this class.  Now that I've gone over to 8.20 the .vi no longer works.  I the property and method nodes have no available methods or properties???  I am also using another client class that is working just fine even in 8.20?  Anyone else seen anything like this?