Re: "Insufficient state to deserialize the object" error

From: Ken Kolda (ken.kolda_at_elliemae-nospamplease.com)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 10:59:09 -0800

The delegate itself is a serializable object, so both client and server need
to have the definition for it (in the same assembly, same namespace).
Internally, a delegate holds two pieces of data:

* A reference to an object of type MethodInfo, which is also serializable,
that references the method that is to be invoked when the delegate is
called.

* A reference to the object instance on which the method is to be invoked,
assuming the method is an instance method of a class. This is called the
Target of the invocation.

In your code, the MethodInfo corresponds to the method ElanRemoteResponse
and the object on which it is to be invoked is the object referenced by
"this".

So, when the delegate is serialized, both the method info and the target
object must also be serialized on the client and deserialized on the other
end. Since the target object is MarshalByRef (at least it generally should
be the case for remoting events since you want the event raised on the
client), the Target object will be serialized as an ObjRef. So when the
delegate is deserialized on the server, it will be holding proxy for its
target object.

When the server converts the ObjRef to a proxy, it needs to have the
definition for the class that defines the object's type (i.e. the type of
"this" in your code). So, if "this" references a class in your client
assembly, the server will have to have access to it. That's generally not
what you want -- the server shouldn't need knowledge of the client
implementation to raise the event.

So, that's why people use event wrapper classes. An even wrapper class is a
MarshalByRefObject-derived class that is defined in an assembly shared by
client and server and exposes a method that matches the signature of the
server's event. When the client wishes to subscribe to an event, it creates
a wrapper around the real recipient and passes the wrapper to the server.
When teh event is raised, the wrapper simply forwards the event to the
wrapped object. This one level of indirection removes the need for the
client implementation to be accessible to the server.

Hope that helps -
Ken

"John Olbert" <someone@snet.net> wrote in message
news:3C012797-8F95-4926-97E2-F1D7A32461B7@microsoft.com...
> Thanks.
>
> I tried using the .NET Configuration Tool to give the mapped drive Full
> Trust but that did not solve the problem. I will work on the name question
> but it does raise another question.
>
> The line that throws the exception is--
> iConnect.ElanAsynchResponse += new
> Sciex.Elan.INexusLayer.ElanResponseHandler(this.ElanRemoteResponse);
>
> This is the Client side subscribing to an event on the Server but is not
the
> actual execution of the event. What is passed during the subscription
process
> that requires serialization?
>
> Again, any help would be appreciated. I definitely appreciate what you
have
> sent.
>
> --John
> javo2000@snet.net
>
>
> "Ken Kolda" wrote:
>
> > If any of the assemblies are being loaded from the mapped drive, I
believe
> > this could be a problem. .NET generally loads loads these types of
> > assemblies with less than full trust, which can cause errors during
> > serialization/deserialization.
> >
> > That said, your issue of multiple assemblies with the same name sounds
> > potentially problematic as well. I wasn't able to follow exactly which
> > classes/interfaces are defined in which assembly, but if any of your
remoted
> > types (either serializable or marshal-by-ref) are defined in either of
the
> > assemblies with the same name, this could likely be the cause of your
> > problems. When an object is serialized or passed by reference, it
includes
> > the name of the assembly in which it resides. If the assembly with that
name
> > doesn't contain the specified class when it's received on the other end,
> > you'll certainly get an error.
> >
> > Ken
> >
> >
> > "John Olbert" <someone@snet.net> wrote in message
> > news:8212261F-5111-4841-B8AF-8551B33E5BD9@microsoft.com...
> > > Ken--
> > > I wanted to add another item to the first reply.
> > >
> > > The team that wrote and setup this project also is using a locally
mapped
> > > drive. The drive X: is assigned to the location of the Server using
the
> > > following Bat file code in Dos--
> > > subst x: /d
> > > subst x: "c:\elan 3.3"
> > >
> > > This may also be connected to the problem. Unforunately we do not
control
> > > this issue either.
> > >
> > > Thanks again.
> > >
> > > --John Olbert
> > > javo2000@snet.net
> > >
> > >
> > > "Ken Kolda" wrote:
> > >
> > > > A couple of things to check:
> > > >
> > > > 1) The object which is represented by "this" in your code should be
an
> > > > instance of a class that derives from MarshalbyRefObject.
> > > >
> > > > 2) The server will need to have access to the assembly which
contains
> > the
> > > > definition of the class references by "this".
> > > >
> > > > If you want to avoid these two requirements, then you need to create
an
> > > > event wrapper class. This class is a MarshalbyRefObject-derived
class
> > which
> > > > you would define in an assembly that would be shared by the client
and
> > > > server. It basically exposes a method to receive the event callback
and
> > then
> > > > forwards that call on to your non-remotable class.
> > > >
> > > > If you need additional details, or if this doesn't solve the
problem,
> > post
> > > > back.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "John Olbert" <someone@snet.net> wrote in message
> > > > news:694B0552-DDED-4913-8DF6-2808CD95FBB7@microsoft.com...
> > > > > I have a situation in which a Server exposes an event but when the
> > client
> > > > > tries to add the subscribe to the event the following error is
> > generated--
> > > > > "Insufficient state to deserialize the object. More information
is
> > > > needed."
> > > > >
> > > > > The Client side code is below--
> > > > >
> > > > > public INexusToTerrapin iConnect = null;
> > > > > public INexus()
> > > > > {
> > > > > try
> > > > > {
> > > > > HttpChannel myChannel = new HttpChannel(0);
> > > > > ChannelServices.RegisterChannel(myChannel);
> > > > > iConnect =
> > > > >
> > > >
> >
(INexusToTerrapin)Activator.GetObject(typeof(INexusToTerrapin),"http://local
> > > > host:1234/TerrapinConnectionHelper.soap");
> > > > > iConnect.SetTerrapinToNexus(this);
> > > > > iConnect.ElanAsynchResponse += new
> > > > >
Sciex.Elan.INexusLayer.ElanResponseHandler(this.ElanRemoteResponse);
> > > > > }
> > > > > catch (Exception e)
> > > > > {
> > > > > Trace.Write("Terrapin.INexus c'tor error " +
e.Message);
> > > > > }
> > > > > }
> > > > >
> > > > > The runtime error (both Server and Client build fine) occurs at
the "
> > > > > iConnect.ElanAsynchResponse +=" code.
> > > > >
> > > > > There is a "using" statement and Reference for the namespace and
> > module
> > > > that
> > > > > contains the ElanResponseHandler delegate, the interface
> > INexusToTerrapin
> > > > > and the class that implements the interface (for example the
> > > > > SetTerrapinNexus() function).
> > > > >
> > > > > If the code for the delegate and implementation class is moved
into
> > the
> > > > same
> > > > > namespace as the code above everything works fine but if they are
in
> > > > separate
> > > > > namespaces this runtime problem occurs.
> > > > >
> > > > > Because of various development constraints we cannot put them in
the
> > same
> > > > > namespace.
> > > > >
> > > > > Any help would be appreciated.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > --John Olbert
> > > > > javo2000@snet.net
> > > > >
> > > > >
> > > > > --
> > > > > John Olbert
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >

Relevant Pages

  • Re: soapsuds
    ... > the 'server' assembly, then the soapsuds extraction falls over. ... > in .Net that namespaces cannot span assemblies? ... > interface defined in a shared assembly (which can be implemented my other ... dll which sits both on the server and the client allowing objects to talk to ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: delegate question
    ... information of the method that the delegate is attached to. ... the server, and never get to you (a copy of your client will be sent to the ... event is remoted back to the client, ... the> client-runtime throws serialization exceptions of classes that are not> relevant for my client. ...
    (microsoft.public.dotnet.framework.remoting)
  • Assembly Versioning Advice: Client needs to talk to 2 servers w/ different versions
    ... interface contract. ... thought this would be enough for the client to talk with the server. ... but when an exception is generated by the server it ... assemblies on the client-side. ...
    (microsoft.public.dotnet.general)
  • Re: Problem with serializing business object instead of core objects
    ... code implementation deployed to the client. ... forth) in a separate DLL that is used by both the server and client. ... > serialization info), these type definitions will not be recognized as the ... > client and server assemblies. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Problem with serializing business object instead of core objects
    ... My guess is that you have defined the RemoteTest class twice -- once in your ... server assembly and once in the client assembly. ... client and server assemblies. ...
    (microsoft.public.dotnet.framework.remoting)