Hello Mark.
Is it possible for me to serialize and deserialize a list directly? Like
this:
public static void Serialize<T>(T obj, string filename)
{
//Serialize
using (FileStream stream = File.Open(filename, FileMode.Create))
{
Serializer.Serialize(stream, obj);
}
}
public static T Deserialize<T>(string filename)
{
//Deserialize
using (FileStream stream = File.Open(filename, FileMode.Open))
{
return Serializer.Deserialize<T>(stream);
}
}
Where T : List<Client>
Thank you
- Dan
On Thursday, June 28, 2012 1:51:14 PM UTC+1, Joel Carrier wrote:
>
> Yes it does. Thanks.
>
> Where can I read more about this disabling of list-handling and its
> effects?
>
> On Thu, Jun 28, 2012 at 8:31 AM, Marc Gravell
> <marc.g...@gmail.com<javascript:>
> > wrote:
>
>> Well, until I get around to re-implementing it for v2, GetProto<T> will
>> just make a quiet apology. But to answer your question, consider an example
>> such as ItemList<Customer>
>>
>> Item<TItem> could be (I can't remember how v1 implements this) something
>> like
>>
>> message Item_Customer {
>> optional Customer Item = 1;
>> }
>>
>> On the subject of ItemList<TItem> - unless you disable list-handling
>> (separate topic), this will be treated *entirely* as just a List<TItem> -
>> so no specific message is generated. As per my previous comment, such a
>> list is then semantically identical to
>>
>> message SomeWrapper {
>> repeated Item_Customer Items = 1;
>> }
>>
>> Make sense?
>>
>> Marc
>>
>> On 28 June 2012 13:24, Joel Carrier <jo...@joelcarrier.com
>> <javascript:>>wrote:
>>
>>> Thanks a lot for the explanation Marc.
>>>
>>> I'm currently investigating some interop issues we're having and I'm
>>> starting to realize that this might be the source of the problem.
>>>
>>> [CollectionDataContract(Name = "ItemList")]
>>> public class ItemList<TItem> : List<Item<TItem>> where TItem : class
>>> ...
>>> where
>>>
>>> [DataContract(Name = "Item")]
>>> public class Item<TItem> where TItem : class
>>> {
>>> [DataMember(Order = 1, Name = "Item")]
>>> public TItem Item { get; set; }
>>> ...
>>>
>>> The TItems are classes generated from .proto files. So we're mixing the
>>> functionality (annotated classes vs. proto files).
>>>
>>> I think we're breaking a lot of "rules" here and I'm wondering how this
>>> could ever generate valid .proto files.
>>> That is, if it were to work, I have trouble picturing what Serializer.
>>> GetProto<ItemList>() might output.
>>>
>>> This does appear to be working between clients using protobuf-net but I
>>> guess what I'm looking for is confirmation that this would probably not
>>> work nicely interop-ing with other Protocol Buffer libraries.
>>>
>>> (Note: I'm new to this stuff, so if I'm not making any sense at all let
>>> me know and I'll return with a smarter question.)
>>>
>>>
>>> Joel
>>>
>>>
>>> On Wednesday, June 27, 2012 4:07:49 PM UTC-4, Marc Gravell wrote:
>>>>
>>>> The data is of course compatible. A `List<Foo>` is directly mappable to
>>>> .proto via for example:
>>>>
>>>> message SomeOuterMessage {
>>>> repeated Foo items = 1;
>>>> }
>>>>
>>>> In fact, for that reason, serializing a List<Foo> will produce
>>>> **exactly** the same data on the wire as serializing:
>>>>
>>>> [ProtoContract]
>>>> public class Whatever {
>>>> [ProtoMember(1)]
>>>> public List<Foo> Items {get;set;}
>>>> }
>>>>
>>>> which is (give or take) what you will get if you feed the above .proto
>>>> into "protogen" (protobuf-net's entirely optional code generator for
>>>> handling .proto definitions)
>>>>
>>>> Marc
>>>>
>>>>
>>>>
>>>> On 27 June 2012 16:21, Joel Carrier <jo...@joelcarrier.com<javascript:>
>>>> > wrote:
>>>>
>>>>> Hi Marc,
>>>>>
>>>>> Could you elaborate on your note: (note: this is specific to
>>>>> protobuf-net, not "protocol buffers" more widely)
>>>>>
>>>>> What are the implications if communicating with non-protobuf-net
>>>>> targets? (ie. java, python, ... applications)
>>>>>
>>>>> Joel
>>>>>
>>>>>
>>>>> On Wednesday, June 20, 2012 9:05:49 AM UTC-4, Marc Gravell wrote:
>>>>>>
>>>>>> (note: this is specific to protobuf-net, not "protocol buffers" more
>>>>>> widely), but yes: that (a generic list) would work fine, as long as the
>>>>>> property has been marked for serialization and given a number. There
>>>>>> also
>>>>>> doesn't need to be a "set" accessor, although it can make full use of a
>>>>>> "set" - i.e. if it finds the list is "null", it will create a new list
>>>>>> of
>>>>>> the appropriate type and use the "set" to update the object.
>>>>>>
>>>>>> So, your code would be fine if it has been designated a number, or a
>>>>>> related example:
>>>>>>
>>>>>> [ProtoMember(4)]
>>>>>> public List<Order> Orders { get { return orders; } }
>>>>>> private readonly List<Order> orders = new List<Order>();
>>>>>>
>>>>>> Marc
>>>>>> (protobuf-net)
>>>>>>
>>>>>> On 20 June 2012 13:08, Farooq Mushtaq <farooqm...@gmail.com<javascript:>
>>>>>> > wrote:
>>>>>>
>>>>>>> How can we serialize list of objects by using protobuf-net? Is
>>>>>>> protobuf-net support list of objects like
>>>>>>> public List(ABC) DEF
>>>>>>> {
>>>>>>> get;
>>>>>>> set;
>>>>>>> }
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Protocol Buffers" group.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/**ms**g/protobuf/-/W0yySDcbES8J<https://groups.google.com/d/msg/protobuf/-/W0yySDcbES8J>
>>>>>>> .
>>>>>>> To post to this group, send email to
>>>>>>> prot...@googlegroups.com<javascript:>
>>>>>>> .
>>>>>>> To unsubscribe from this group, send email to protobuf+u...@**
>>>>>>> googlegro**ups.com <javascript:>.
>>>>>>> For more options, visit this group at http://groups.google.com/**
>>>>>>> group**/protobuf?hl=en<http://groups.google.com/group/protobuf?hl=en>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>> Marc
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Protocol Buffers" group.
>>>>> To view this discussion on the web visit https://groups.google.com/d/*
>>>>> *msg/protobuf/-/2pcXp7q9LCcJ<https://groups.google.com/d/msg/protobuf/-/2pcXp7q9LCcJ>
>>>>> .
>>>>>
>>>>> To post to this group, send email to prot...@googlegroups.com<javascript:>
>>>>> .
>>>>> To unsubscribe from this group, send email to protobuf+u...@**
>>>>> googlegroups.com <javascript:>.
>>>>> For more options, visit this group at http://groups.google.com/**
>>>>> group/protobuf?hl=en <http://groups.google.com/group/protobuf?hl=en>.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Marc
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/protobuf/-/SUzHf4_n0O4J.
>>>
>>> To post to this group, send email to prot...@googlegroups.com<javascript:>
>>> .
>>> To unsubscribe from this group, send email to
>>> protobuf+u...@googlegroups.com <javascript:>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/protobuf?hl=en.
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Marc
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/protobuf/-/WKcb-zQUieIJ.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
