Exception When Returning Serializable Object from a Remoted Server

[GoogleCodeExporter]

Please include an e-mail address if this might need a dialogue!
==============
contact: dburns.2103@gmail.com

What steps will reproduce the problem?
1. Create a serializable class like the example.
2. Make the class a return type of a remoted server.
3.

What is the expected output? What do you see instead?
In my application, the Serializer.Merge() call in ISerializer.GetObjectData() 
throws and exception with the message "Member 'proto' was not found"

What version of the product are you using? On what operating system?
v. 2.0.0.480
Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by dBurns.2...@gmail.com on 13 Mar 2012 at 8:59

[GoogleCodeExporter]

That's odd; in this scenario, are both ends up to date with the correct version 
of your object dll?

Original comment by marc.gravell on 14 Mar 2012 at 6:38

[GoogleCodeExporter]

Yes, because I'm running client and server in visual studio debugger.  
Additionally, the DTO is located in the server's assembly, and the client has a 
dependency on it.  A mismatch would occur only if I'm running x64 server and 
x86 client, which would result in separate bin directories (not the case here). 
 The weird part is, I don't even have a member called "proto".  Any additional 
thoughts?  Perhaps, I'm not setting up the DTO's attributes correctly.  I 
followed the Remoting example provided in the wiki.

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 1:42

[GoogleCodeExporter]

Some additional notes.  I'm confused about decorating the DTO members.  Which 
attributes should I use?  I'm currently using ProtoContract and ProtoMember.

See: 
http://stackoverflow.com/questions/6478579/improve-binary-serialization-performa
nce-for-large-list-of-structs

This post suggest using DataContract and DataMember.

However, the pages at http://code.google.com/p/protobuf-net/wiki/GettingStarted 
and 
http://code.google.com/p/protobuf-net/source/browse/trunk/Examples/Remoting.cs?r
=53 
say to use ProtoContract and ProtoMember.

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 1:49

[GoogleCodeExporter]

"proto" is, I assume, just the key against which I store the chunk of data for 
this scenario. Re attributes - either is fine; simply: the system allows you to 
re-use DTOs that have been decorated with attributes from some other engines 
(WCF, for example), without needing to specifically reference protobuf-net; 
however, the ProtoContract/ProtoMember attributes allow more control over a few 
things.

I will try to repro... or: do you have a minimal repro for this?

Original comment by marc.gravell on 14 Mar 2012 at 2:22

[GoogleCodeExporter]

Here we go; seems fine: http://pastie.org/3593817

If I had to guess: you have the Serialize and the Merge the wrong way around in 
the GetObjectData() / .ctor()

Original comment by marc.gravell on 14 Mar 2012 at 2:30

[GoogleCodeExporter]

Unfortunately, I don't have minimal code.  I can try to set up a sample project 
this morning.  Shouldn't take much.  Just need a client, a remoted server, and 
a metohd on the server that returns the DTO.

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 2:30

[GoogleCodeExporter]

Can you check against the pastie above? in particular, check the Serialize and 
Merge in your GetObjectData() and .ctor()

Original comment by marc.gravell on 14 Mar 2012 at 2:33

[GoogleCodeExporter]

Checking now... 

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 2:35

[GoogleCodeExporter]

Seems to be working now.  I have some deserialization issues that need ironed 
out, but aren't related to ProtoBuf.  Need to work on a different task now, but 
will status you COB today with update and performance metrics.  Thanks for the 
help.

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 2:48

[GoogleCodeExporter]

Original comment by marc.gravell on 14 Mar 2012 at 2:55

• Changed state: Invalid

[GoogleCodeExporter]

FYI, using default BinaryFormatter took client to server an average of 45 
seconds roundtrip.  Using ProtoBuf, the time was reduced to ~100ms.  
Unbelievable improvement.  Thanks for a great library.

Original comment by dBurns.2...@gmail.com on 14 Mar 2012 at 9:56

[GoogleCodeExporter]

@dBurns.2103 that sounds very impressive, but sounds *too* good. Please 
validate that all the data you expect is actually there - I wouldn't want you 
to lose data. For large-ish objects, it is reasonable to expect to see a 
significant improvement, but 45s => 100ms sounds unlikely, even for protobuf-net

Original comment by marc.gravell on 14 Mar 2012 at 11:32

[GoogleCodeExporter]

All my data can be verified through the GUI, but I'm getting screwy results for 
a few arrays I'm passing back.  I populate 2 string arrays with one element 
each.  When they are deserialized, the arrays are null.  I tried populating 
each array with 4 elements.  The deserialization produced 1 element per array.  
Weird.

Additionally, I'm having trouble with byte arrays explained here. 
http://code.google.com/p/protobuf-net/issues/detail?id=278&sort=-id

I don't fully understand the ins and outs of your product, so I appreciate the 
help.

Original comment by dBurns.2...@gmail.com on 15 Mar 2012 at 2:57

[GoogleCodeExporter]

The issue with the string array is resolved.  If you pass a 0 element array to 
the serializer, it deserializes as null.  This was causing an error and 
prevented my data from arriving at the GUI.  I fixed this by providing a 
private backing property and a client accessor property as such:

[ProtoMember]
private string[] _data
{
    get;
    set;
}

public string[] Data
{
    get
    {
        if(_data == null)
            _data = new string[0];
        return _data;
    }
}

The byte array fix is similar and can be found here.
http://code.google.com/p/protobuf-net/issues/detail?can=2&start=0&num=100&q=&col
spec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sort=-
id&id=278

Additionally, I should add the null check logic to the byte array fix.  Based 
on other issues/responses, does this seem like a sensible solution?  I couldn't 
find any other way to handle 0 element arrays.

Original comment by dBurns.2...@gmail.com on 15 Mar 2012 at 6:48