LabView 7.1 and .NET Dlls problem

[wjousts]

I'm having a problem that is really driving me nuts. The setup heres a
little complicated, so please bare with me:
I have a dll, written in C#.NET, that contains a class, let's call it
Manager, it's job is to search a directory, find other dlls and search
them for classes that implement a certain interface, lets call it
ICalc. It uses Assembly.LoadFrom to do this. It maintains a list of all
the classes it finds that implement ICalc (in an arraylist of Type
objects) and returns information about those classes (name and version)
to the client program. Manager also has a method, let's call it
GetCalc, that will instantiate and return an object that implements
ICalc of a type requested by the caller. So far so good, and this seems
to work okay.
Now I have another dll that contains a class, lets call it MyCalc that
implements ICalc. When MyCalc is instantiated it must instantiate a few
other objects that are related to its function. Among these are a class
that contains some settings, lets call it MySettings. These settings
are actually serialized to the disk and deserialized again by MyCalc
using a static method in MySettings, something like:
public static MySettings LoadSettings(string filename)
Hopefully, you are still following this. Now, I create a simple C#
console application to test this out and everything works fine -
great!! But here's the problem, I'm trying to use LabView as the client
for the Manager Dll and this is were I run into trouble. For some
reason the deserialization no longer works and chokes with an "Invalid
Cast" exception. Basically the line:
MySettings setting = (MySettings) MyFormatter.Deserialize(MyStream)
Doesn't work.
Does anybody have any clue why this might be? I'm really confused by
this. What is LabView doing different from a simple console application
that is causing this to fail?
I'm using LabView 7.1 and .NET 1.1 at the moment.

[Lycangeek]

I'm not certain, but it may be due to the various assemblies being loaded in different context's (LoadFrom is evil in general and makes life much more complicated - we use it as well, but the pain it causes is not small). Can you

a. Post the assembly and VI so I can try it?

and/or

b. Try it out in LV 8 (you can download an eval if you don't have it)

The LV 8 is because we changed the order in which we attempt to load the assembly. In 7, it was LoadFrom then Load. In 8, we do Load and then LoadFrom. Take too much time to explain the differences there, but if that fixes it and you want to know, I can go into more detail.

[wjousts]

Thanks for your reply.

So I tried LV8 and it seemed to make things worse. I was getting exceptions thrown even when trying to load the assemblies in the first place. So I looked online a bit and found a suggestion to try LoadFrom instead of LoadFile. Looking at MSDN LoadFile is described as:

Loads the contents of an assembly file on the specified path.

And LoadFrom is described:

Loads an assembly given its file name or path.

So that's perfectly clear then! Anyway, I tried it and it worked. It fixed my problem in LV8 and even fixed it in LV7.1. Well sort of. What I didn't mention before is that in my dll I actually have two classes that are deserialized. One contains settings and is serialized as XML (for easy editing) and now deserializes quite nicely The trouble is that the other one contains data, sensitive data, so I have it saved using a BinaryFormatter which first passes through a CryptoStream using RijndaelManaged to encode the data. Basically, when serializing the object is converted into a binary stream, passed through a cryptostream and then written to the disc. When deserializing the object is loaded from the disc, passed back through the crypto stream and when reconstructed into the original object. At least, that's how it works "in theory". As you've no doubt guessed, it doesn't work in practice. It works fine again from a .NET console app, but not from LV. The exception thrown complains about version incompatibility because it expects verions 1.0 and recieved version 1625312273.10500200! I know from bitter experience that this is the result of the decoding not working so the stream that is supposed to be the object is full of junk.

Does anybody know if there is a problem with using the .NET cryptography classes in LV?

Thanks

[wjousts]

Actually, nevermind. It was a bug on my end. Everything seems to be working now.

Thanks for your help.

[Lycangeek]

Sorry for the confusion. Your post had said you were using LoadFrom so I didn't spot the problem, but yes, LoadFile won't work for anything you want to execute. Here is the key information from MSDN

Use the LoadFile method to load and examine assemblies that have the same identity, but are located in different paths. Do not use LoadFile to load assemblies that you want to execute. LoadFile does not load files into the LoadFrom context, and does not resolve dependencies using the load path, as the LoadFrom method does. LoadFile is useful in this limited scenario because LoadFrom cannot be used to load assemblies that have the same identities but different paths; it will load only the first such assembly.

Again you see mention to the issue on load contexts, which is very poorly documented and very confusing. However, if you ever have a desire to mess with your head, here are a couple of blogs by Microsoft developers who work with this: http://blogs.msdn.com/suzcook and http://blogs.msdn.com/junfeng. The blogs are very good, but getting your head around Load vs. LoadFrom, contexts and fusion rules can be painful. 

[wjousts]

Thanks for your help Brian. I really did think I had put LoadFrom and not LoadFile in my original code, I guess Intellisense sometimes can get you in trouble. It's just really weird that it worked from my .NET console app. Perhaps it only worked because they were all in the same solution even though by console app didn't have a reference to the dll?

Thanks for the helpful links too. I'd see the Suzanne Cook blog before, but the other one I hadn't seen. I will have to try and wrap my head around it sometime. The MSDN documentation is quite confusing on this subject which is especially frustrating when MSDN is usually such a good resource.