InvalidCastException on a Deserialized object inside aTransperantProxy call

[roynevo]

Hi,

I'm trying to deserialize an object on the context of a remoting call
(RPC).
The deserialization seem to work fine, however when I'm casting the
result to the relevant class I get an InvalidCastException.

Note:
* the remoting server has TypeFilterLevel to Full to remove security
restrictions.
* the casting has no problem when done in the immediate window, or in
another application without remoting involved.
* The serializing and deserializing DLL's are the same and from the
same build.


void func() // called by Remoting
{
Stream myStream = File.OpenRead(shortFileName +
"_env_stream.bin");
object obj = bf.Deserialize(myStream); // bf is of
type BinaryFormatter
myClass = (MyNameSpace.MyClass)obj; // ERROR - InvalidCastException

Assembly a =
System.Reflection.Assembly.GetAssembly(myClass.GetType());
Assembly b =
System.Reflection.Assembly.GetAssembly(obj.GetType());
bool isSameAssembly = a.Equals(b); // this is False
when func is called in Remoting
}

 

[Ashutosh Bhawasinka]

Where is the MyNameSpace.MyClass declared?

It should be in a common assembly which is being used by both the ends.
Just having the same code (even the same namespace) in both the client
and the server doesn't make the class same.

When you cast it, apart from the class name, it's assembly name is also
compared.

Thanks & Regards,
Ashutosh

 

[Adam Benson]

Check that your exe can only get at one copy of the dll in question.

Something that's happened to me on occasion is that an exe has 2 copies of
the same dll available to it. This can happen if you build your exe to one
directory, and put your dlls in a "libs" sub-directory. If the dll ends up
in the same directory as the exe, and in the libs directory as well (by some
mistake in the build process, or copying by accident) then 2 copies of the
dll end up getting loaded - one from one directory, and another from a
different directory. An object created by, or deserialized by one instance
of the dll cannot be accessed by the other version.

This scenario might not fit your probem at all, of course, but I thought it
was worth mentioning.

Cheers,

Adam.
============

 

[Roy Nevo]

Yes it is loaded from the same assembly.

the serializing program has the exact same complied DLL as the
desrializing.

Thanks,

Roy.

 

[Roy Nevo]

Check that your exe can only get at one copy of the dll in question.

Something that's happened to me on occasion is that an exe has 2 copies of
the same dll available to it. This can happen if you build your exe to one
directory, and put your dlls in a "libs" sub-directory. If the dll ends up
in the same directory as the exe, and in the libs directory as well (by some
mistake in the build process, or copying by accident) then 2 copies of the
dll end up getting loaded - one from one directory, and another from a
different directory. An object created by, or deserialized by one instance
of the dll cannot be accessed by the other version.

This scenario might not fit your probem at all, of course, but I thought it
was worth mentioning.

Cheers,

Adam.
============

Hi Adam,

this is not the case, the dll's are from the same assembly.