Re: Protobuf-net Serialize problem

2009-04-10 Thread test.f...@nomail.please
Marc, another issue is that for optional string fields, protogen defaults to "". Shouldn't it default to null? optional string clientid = 2; private string _clientid = ""; [ProtoBuf.ProtoMember(2, IsRequired = false, Name = @"clientid", DataFormat = ProtoBuf.DataFormat.Default)]

Re: Protobuf-net Serialize problem

2009-04-09 Thread test.f...@nomail.please
Marc, ACtually, not using detectMissing will fix the string serialization but not the primitive types which would default to default(T). How will protobuf-net serialize the field if I munged the signature as public int? Foo { get; set; } Thanks --~--~-~--~~~---~--~-

Re: Protobuf-net Serialize problem

2009-04-09 Thread test.f...@nomail.please
Marc, We figured out the problem. I had to send it over TIBCO as byte[] and on the server side, it had to be pulled out as tibrv_u8array. After that, the protobuf string conversion worked. However, I noticed couple of odd things in this latest release of protobuf-net. 1) It seems that an Option

Re: Protobuf-net Serialize problem

2009-04-07 Thread Marc Gravell
I'm not an expect on TIBCO messages; and I'm not sure what AddField (string,byte[]) method you are talking about, sorry. But if that is a Tibco method for packing a (named) byte[] into a Tibco message, then it sounds ideal. Serialize to a MemoryStream and use .ToArray() to get the byte[] - for ex

Re: Protobuf-net Serialize problem

2009-04-07 Thread test.f...@nomail.please
Marc, Yes, we suspect the problem is in the transmit from .Net as well due to the truncation at 1st NULL char in the Unicode string. I'm sending the data back as a TIBCO message which also adds the field as a string. Do you think if I use the AddField(string, byte[]) overload, it'll work on the s

Re: Protobuf-net Serialize problem

2009-04-04 Thread Marc Gravell
I've just been looking more - and ParseFromString should do the job. I /suspect/ the problem is the definition a "string"... you aren't going to be able to treat raw binary in .NET as a String; you are going to have to treat it as a Stream or a byte[], or you can encode it to base-64 (as above) to

Re: Protobuf-net Serialize problem

2009-04-04 Thread Marc Gravell
OK; can I clafy then; the server is using the standard C++ version of ProtoBuf 2.0.1, and the client is protobuf-net (recent version), and you are having difficulty using ParseFromString in the C++ version. Is that correct? I will need to check (Kenton?) what format ParseFromString is expecting,

Re: Protobuf-net Serialize problem

2009-04-03 Thread test.f...@nomail.please
Marc, The server is using ProtoBuf 2.0.1. I had to upgrade my .net version to the latest protobuf-net in order to have protogen work with optional fields correctly. It seems that the server only processes bytes up to the 1st NULL char when calling ParseFromString. Will this problem be avoided w

Re: Protobuf-net Serialize problem

2009-04-02 Thread Marc Gravell
(re last post) As with unicode, you can't use ASCII to handle raw binary; either use base-64 (previous post), or send binary. Marc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to

Re: Protobuf-net Serialize problem

2009-04-02 Thread Marc Gravell
You can't use unicode to transport arbitrary binary data - it won't be a valid unicode string. If you have to use strings, then base-64 is the safest option: private string Serialize(OrderProto proto) { using (MemoryStream stream = new MemoryStream()) {

Re: Protobuf-net Serialize problem

2009-04-02 Thread Marc Gravell
Quick question - which build are you using? (at client and server)? Based on the field names, the code-generation dates back to November; if the dlls are aged similarly, it is possible that this is an old bug. If possible, can you retry with the current build? I'm just trying the code you posted

Re: Protobuf-net Serialize problem

2009-04-02 Thread test.f...@nomail.please
Well, this code certainly passes the unit test of comparing before and after protobufs. But the string still fails to be recognized as a valid protobuf object on the server. Any ideas? Thanks private string Serialize(OrderProto proto) { using (MemoryStream stream = n

Re: Protobuf-net Serialize problem

2009-04-02 Thread test.f...@nomail.please
Actually, I was wrong, this code produces an empty string. The following code serializes *something* which fails on the server side on ParseFromString. Any ideas what I have to do to correctly serialize this? private string Serialize(OrderProto proto) { using (MemoryS

Re: Protobuf-net Serialize problem

2009-04-02 Thread test.f...@nomail.please
It seems I was wrong in trying to use ASCII or UTF-8 encoding. This works. private string Serialize(OrderProto proto) { using (MemoryStream stream = new MemoryStream()) { Serializer.Serialize(stream, proto); using (StreamRead

Re: Protobuf-net Serialize problem

2009-04-02 Thread test.f...@nomail.please
Marc, Thanks for responding. As I'd mentioned, the server is expecting the proto serialized as binary and passed as a string param. It's doing the following. Order::ProtoBufType sourceBuff; if(!sourceBuff.ParseFromString(params["Order"]->string_value())) { // exception I'm able to g

Re: Protobuf-net Serialize problem

2009-04-02 Thread Marc Gravell
Hi; I'm the author of protobuf-net, and I hope I can help you find what is going on here... The binary format should be compatible between platforms (that is the point, after all). Are you able to share your OrderProto class with me? Either here, or at marc.grav...@gmail.com. The base-64 should b

Protobuf-net Serialize problem

2009-04-01 Thread test.f...@nomail.please
Does someone have a Serialize sample for protobuf-net? I'm using VS 2005/C#. When I try Encoding.ASCII.GetBytes() and Encoding.ASCII.GetString(), I get an exception "invalid wire type - 7". If I Convert.FromBase64String, serialize/deserialize works but the message is rejected by the server which