Serialization of System::Int32^ problem

G

Guest

I'm developing a client/server application (in VS2005 managed C++) which
makes use of .Net remoting. A simplified solution which demonstrates the
problem I'm having can be found at:

http://www.nmt.edu/~elessar/RemotingTest.tar.bz2
http://www.nmt.edu/~elessar/RemotingTest.zip

Uncommenting Server.cpp line 67 causes the problem. Removing it fixes the
problem. The server listens on port 1357, and the client connects to
localhost:1357.

I've defined the following classes in an assembly referenced by both the
client and the server:

[System::Serializable]
public ref class ExchangeObject
{
public:
ExchangeObject::ExchangeObject();
System::Object ^myob;
System::Int32 ^myint;
};

public delegate void ObjectHandler (General::ExchangeObject ^object);

public interface class IRemoteClient
{
public:
void Object_For_Client (General::ExchangeObject ^exch_ob);
};

public interface class IRemoteServer
{
public:
int AddClient (General::IRemoteClient ^client);
void RemoveClient (int client_id);
void Object_For_Device (General::ExchangeObject ^exch_ob);
};

Obviously, the client implements IRemoteClient, and the server implements
IRemoteServer. Both are MarshalByRef. When the server starts, it creates an
instance of the server class, then publishes it with

System::Runtime::Remoting::RemotingServices::Marshal

The client creates an instance of the client class, gets a reference to the
remote server, then passes a reference to the client object to the server,
using the AddClient() method. Once the connection is established, the client
and server can exchange messages by calling the Object_For_Client() and
Object_For_Server() methods. This is all working just fine.

The problem arises when I put a value in the myint field of the
ExchangeObject. As long as the field is a nullptr, everything is fine. If I
put a reference to a System::Int32 in myob, things are also fine. However,
if I initialize the myint field with something like:

exch_ob->myint = gcnew System::Int32(42);

then the object will no longer properly serialize. When the server tries to
call Object_For_Client with the object, it throws a

System.Runtime.Serialization.SerializationException

Binary stream '42' does not contain a valid BinaryHeader. Possible causes
are invalid stream or object version change between serialization and
deserialization.

Suspiciously, the referenced binary stream is the same number as the integer
I was trying to send, and it changes to match when I change the integer. At
this point, I'm suspecting that this is a bug in the compiler or framework,
but I'm hoping that it's just something I've done wrong, so I can fix it.
Any suggested fixes or workarounds would be greatly appreciated.

Thanks for any help and suggestions,
-Thomee Wright-
 
L

Luke Zhang [MSFT]

Hello Thomee,

Thank you for the posting. I have download your sample and studying on it.
I will update you as soon as possible. If you also have any progress,
please let us know.

Thanks,

Luke Zhang
Microsoft Online Community Lead

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
L

Luke Zhang [MSFT]

With you sample, I also found the same problem. I agree with you that it is
more like a bug: I searched in our database and found similiar issue
reported as bugs. If the issue really impact your development, I suggest
you may contact our PSS to request a fix or work around. To submit a
support incident, you may go to

http://msdn.microsoft.com/subscriptions/

And click Support Incidents.

Thanks,

Luke Zhang
Microsoft Online Community Lead

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top