Henk:
>Has somebody encountered this problem:
...
>Exception: System.InvalidCastException
Yes, I have seen this. I had the same exact problem a few days ago when
serializing to disk and deserializing back again in the same code -- worked
in a sample program, failed in a NUnit test.
My test looked something like this:
MyType obj = new MyType("foo"); //
typeof(MyType).Assembly.GlobalAssemblyCache is false here
mycode.SaveToDisk(obj); //uses a SoapFormatter to serialize the object
Assert(File.Exists("foo.xml"));
SoapFormatter formatter = new SoapFormatter();
MyType newObj = (MyType) formatter.Deserialize("foo.xml", ...); // error
occurs on the cast
(changing the previous line to this works (of course)):
object newObj = formatter.Deserialize("foo.xml", ...);
newObj.GetType() is still MyType but newObj.GetType
().Assembly.GlobalAssemblyCache is now true
Here is what I have guessed was happening: Since the newObj type
declaration was resolved at compile time, and that type was compiled into
the test code, the reference was to the local copy of the assembly.
However, the serialization call (remoting uses this too) is resolved at run
time, and it looks in the folder of the executing assembly for the assembly
named in the serialization information, and if its not there gets it from
the GAC (earlier I had found that I had to register the test assembly to
get remoting calls to work at all).
I don't know that its elegant, but I just stopped fighting with it, and
moved the type to a different assembly (it was a value type used via an
interface) that was referenced by both the test code and the CUT code, and
registered *that* in the GAC, instead of the test assembly and it worked.
After typing this out, I am guessing that it works either because the
Interface assembly was registered in the GAC *before* compiling the tests,
and so the GAC version was used or perhaps having the type in a different
assembly changes the loading rules even for types resolved at compile time
(but I have no idea why it worked to be honest, I was just glad it did).
Personally, I think its a bug -- maybe not a defect, but a design flaw
since both assemblies are in fact the same code, and have the exact same
signature (same version, same strong key) they should be considered
equivalent IMHO, but perhaps its a security issue (e.g. to prevent
spoofing) I don't know.
Hope this helps.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
