Why does Labview 8.0 upgrade cause broken wires between .NET nodes ?

[Lycangeek]

Glad that this issue is coming to closure for you. I feel bad about these sorts of problems because it's pain you feel due to an early mistake on our part. My apologies.

Since you mentioned the Close Reference, I thought I'd also plug a blog entry I wrote on the subject of when you need to close a .NET reference. You can find it here.

Message Edited by Lycangeek on 09-27-2006 10:37 AM

[batesbc]

Were the corner cases fixed in 8.0.1 also fixed in 8.2? I'm starting to hit a combination of "our .Net calls only work in 8.0.1" plus "we want 8.2 for the new data file stuff"...

[Lycangeek]

Yes - 8.0.1 shipped before 8.2 did, so all of the fixes were included in that source base. What problems are you having in 8.2?

[batesbc]

I'm unable to see public methods of a class that's a property of another class. Attached is a screen cap of what I see in LabVIEW 8.2 as well as from Reflector. The methods exist, the assemblies are all in the GAC, and it works in LabVIEW 8.0.1.

I'll try to get a sample put together, but the code is part of our DB access code, so to actually run it it's looking for a SQL Server 2005 instance. The Cell Env. global is a .Net refnum to an Environment class which holds Adapters for each table in the database. The adapters are set up as properties of the Environment class.

[Lycangeek]

Well, the fact that it's a property should not matter at all - when the refnum flows out of the property node, the next node in the chain has no idea where it comes from...it just knows it's a reference to type xyz. My guess is that it has more to do with the elements of the Adapter class. Looking at the reflector output, it appears that .NET generics are involved, and this could be part of the problem.

Due to a variety of reasons (such as performance on RT), there are code paths through LabVIEW that assume a class name is never longer than 255 characters...In general, this is a fine assumption as no one is likely to name a class something so long. However, .NET generics have incredibly long class names (hidden from the C# programmer through nice little syntax) and they can exceed 255 characters. When this happens, we try to fail gracefully - and that is my guess as to what you are seeing.

I just recently addressed this issue in a bit more detail here...

[batesbc]

Makes sense. We're generating the bulk of that DB layer with CodeSmith anyway, adding the required interfaces shouldn't be a huge problem.

Thanks!

[Joe_H]

If this is true then why did it work in LV8 and it does not work in LV8.20.

Just asking

[Lycangeek]

It was a fail fast versus a fail unexpected. In LV 8.0, we didn't look for the corruption and let some items go through - it all would depend on what code path you took. Because this was considered a bad idea (unexpected failures based on some click or such), we tried to report the failures earlier.