Click here to Skip to main content
15,067,832 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I've created a winForm that has two bindingList that hold two different types of objects. I'd like to serialize both to the same stream which I'm able to do. Next I'd like to be able to deserialize the stream but be able to deserialize each bindList and assign them to new bindingList. Example:
BindingList<myobj1> obj1 = new BindingList<myobj1>() {new MyObj1(), new MyObj1()};
BindingList<myobj2> obj2 = new BindingList<myobj2>() {new MyObj2(), new MyObj2()};

BinaryFormatter serializer = new BinaryFormatter();
Stream strm = File.Create("C:\MyObjDir");
serializer.Serialize(strm, obj1);
serializer.Serialize(strm, obj2);

// Now I want to be able to somehow deserialize them. I know this doesn't work
// but this is along the lines of what I'm trying to accomplish

Stream strm = File.Open("C:\MyObjDir");
BindingList<myobj1> obj1 = (BindingList<myobj1>) serializer.Deserialize(strm);
BindingList<myobj2> obj2 = (BindingList<myobj2>) serializer.Deserialize(strm);
Updated 1-Jun-12 9:42am

You can use Data Contact. Please see:[^].

You may face the problem the Data Contract addresses perfectly: the same object can be referenced in the data more then once, so it can cause infinite recursion in serialization. With Data Contract serializers, you can use the property IsReference of the System.Runtime.Serialization.DataContractAttribute or the parameter preserveObjectReferences in the constructors of the serializers to preserve the object references. It will allow you to serialize an object graph which is not a tree (that is, can contain circular references). Please see:[^],[^].

(I don't see this feature in System.Runtime.Serialization.Json.DataContractJsonSerializer, so you have to use XML-formatted serialization.)

Please see also my past answers where I advocate the Data Contract approach:
How can I utilize XML File streamwriter and reader in my form application?[^],
Creating property files...[^].

d.allen101 1-Jun-12 15:52pm
thx SA, this is exactly what i need. much appreciated!
Great. If so, will you formally accept the answer (green button)? -- thanks.
Sander Rossel 1-Jun-12 16:10pm
My 5. This is the best solution by far, but quite hard to implement (and as I've experienced with XML serialization not always possible due to the strict nature of XML, not sure how that goes with DataContracts though). I've added an easier, but 'quick and dirty' solution just for reference and warned for the dangers. This solution is definitly best.
Thank you very much, Naerling.
Believe or not, right now I'm writing the alternative Data Contract serializer, based on System.Reflection.Emit (otherwise performance is some 100 time worse, because Reflection is too expensive). The difference with Microsoft is that it allows to write different formats (custom or not) based on the same base serializer code. So far, performance is slightly better than Microsoft's even in fully-fledged XML, not per file size though, but per data size, because I write somewhat more compact XML. I mean, I kind of know what am I writing about.
Wait a minute. Using the Microsoft Data Contract serializers is not hard to implement. Just the opposite, it is much easier than using all of the previous serializers. Everything is already implemented. You don't modify your data classes in any way, do not implement and specific interfaces, you just add some .NET attributes to types/members. You don't have to worry about public members -- it will work with private, internal, protected or internal protected. This approach is the most non-intrusive and the easiest to use at the same time.
Sander Rossel 1-Jun-12 17:07pm
I've never used DataContractSerializer... Had a very bad experience with XmlSerializer which made me not want to use XmlSerialization ever again. I ran into problems with trying to Serialize Interfaces, classes without default constructors, dictionaries... I had both my boss and the customer breathing into my neck, and actually I wanted to fix this as soon as possible too since it had given me quite a bad time. So I needed to quickly serialize some stuff, but no. After a few hours of fooling around with XmlSerializer I gave up and used Binary, which I had fixed in five minutes :)
I can clearly understand that. I independently created idea similar to the Data Contract well before it was available (using VS 2005 and v.2.0) to create a light-weight meta-data engine relying totally on Reflection. My problem was that the Reflection was too slow, so my work was only good (and really powerful) only for relatively small files such as configurations, etc. My attempt to preserve some reflected data was not successful. Later on I clearly understood that the only option is using Emit, but it requires good knowledge of IL and Emit itself. I do have it only now.

So, Microsoft Data Contract is the blessing. Just start using it; it's the easiest yet best thing to do in nearly all situations. If I did not want what I want, I would not do anything else, but now I can create something even more powerful...

Sander Rossel 2-Jun-12 3:12am
Next time I'll need to serialize and I have some time to spare (unlike last time) I'll look into DataContract a bit closer :)
Sander Rossel 1-Jun-12 16:26pm
Wow, sounds complex... Things got dizzy before my eyes right when I read 'Emit' ;)
Planning to write a CP article about it?
It depends. The work is commercial, but is we submit one of the standards to the standard organization (on a particular industry standard, very narrow), I would be able to argue in favor of open source part.
Sander Rossel 1-Jun-12 16:56pm
Good luck with that. I hope you'll be able to write something about it.
Read a bit on Reflection.Emit in a book once, but I've never gotten into it (never needed it either). I only had a part of the book, which was to bad, since the other chapters went deeper into the stuff. I'm still waiting for the book to be released. The overall theme of the book is Metaprogramming. I'm going to read it for sure. I've always liked the more abstract stuff :)
Maciej Los 1-Jun-12 16:49pm
Sergey, you're my GURU!
And you are too much... :-)
Thank you, Maciej.
A bit more 'quick and dirty' solution you could try making a BindingList<Object> from the other two BindingLists.
Now when you deserialize it just do something like the following:
BindingList<object> objBl = (BindingList<object>)serializer.Deserialize(strm);
BindingList<myObj1> bl1 = new BindingList<myObj1>(objBl.OfType<myObj1>().ToList());
BindingList<myObj2> bl2 = new BindingList<myObj2>(objBl.OfType<myObj2>().ToList());
Should work, but as I said it's the quick and dirty solution.
I'd take SAKryukov's solution, but since I understand that's not the easiest solution (but best by far) I wanted to give you an easier solution.
Beware though, this might help you out in the short run, but it will come back and bite you later on :)
d.allen101 1-Jun-12 16:09pm
hey naerling it's funny that you gave me that solution because that's exactly what i did lol! i just needed to get my supervisor off of my back. i'll implement SA's solutions over the wkend which is the correct way to go about it. thx anyway for the solution.
Sander Rossel 1-Jun-12 16:12pm
This solution is most obvious I guess. That's why I wanted to mention it and warn for its shortcomings :)
I agree with your judgment on the approach to serialization and its quality. Is it OK that I voted 4 overall? :-)
Sander Rossel 1-Jun-12 16:29pm
I don't mind the 4... I think it's well deserved for a solution that works, does what it should do and keeps it simple, but is not deserving of a prize for beauty and elegance :)
Of course I was just going to edit my answer to include Reflection.Emit... ;p

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900