Serialization of object references
-
Hi guys! I want to (de)serialize a SortedList that contains a couple of "complex" objects. Each of those objects in the list contains two attributes that are references to another objects (they are also stored and (de)serialized in a SortedList). Here's the problem: All references work fine until I serialize and deserialize the data. I compared the deserialized reference with the object it should link to and they are not the same. Before deserialization they are the same. It seems that not the references are serialized but copies of the objects where the references point to. That perhaps makes sense to me cause references are similar to adresses. And adresses surely can change while (de)serialization. So I guess after deserialization I have two separate (but equal) objects and not one object and a reference to it. Is it anyhow possible to (de)serialize object references correctly? Many thanks in advance! :rose: Regards, mYkel
-
Hi guys! I want to (de)serialize a SortedList that contains a couple of "complex" objects. Each of those objects in the list contains two attributes that are references to another objects (they are also stored and (de)serialized in a SortedList). Here's the problem: All references work fine until I serialize and deserialize the data. I compared the deserialized reference with the object it should link to and they are not the same. Before deserialization they are the same. It seems that not the references are serialized but copies of the objects where the references point to. That perhaps makes sense to me cause references are similar to adresses. And adresses surely can change while (de)serialization. So I guess after deserialization I have two separate (but equal) objects and not one object and a reference to it. Is it anyhow possible to (de)serialize object references correctly? Many thanks in advance! :rose: Regards, mYkel
You are correct - references are address, but in the case of the .NET Framework it manages these objects in memory. Since memory address shouldn't be serialized (because the .NET Framework can move these around at any time, which is why the
fixedstatement is needed to work with unsafe memory addresses in C#), you need a serialization manager that can fix-up these objects. With .NET Remoting, the remoting infrastructure does this automatically when marshaling data types acrossAppDomains. Many programs use serialization to save state and exist, restoring that state when the program restarts so such hooks-up aren't needed. You should read through the Serializing Objects[^] section in the .NET Framework if you haven't already. It should cover a few of these things. It's also possible that some things in your list aren't serializable (to be serializable, objects must be attributed with theSerializableAttributeand can optionally implementISerializableto control serialization). Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists?Microsoft MVP, Visual C# My Articles
-
You are correct - references are address, but in the case of the .NET Framework it manages these objects in memory. Since memory address shouldn't be serialized (because the .NET Framework can move these around at any time, which is why the
fixedstatement is needed to work with unsafe memory addresses in C#), you need a serialization manager that can fix-up these objects. With .NET Remoting, the remoting infrastructure does this automatically when marshaling data types acrossAppDomains. Many programs use serialization to save state and exist, restoring that state when the program restarts so such hooks-up aren't needed. You should read through the Serializing Objects[^] section in the .NET Framework if you haven't already. It should cover a few of these things. It's also possible that some things in your list aren't serializable (to be serializable, objects must be attributed with theSerializableAttributeand can optionally implementISerializableto control serialization). Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists?Microsoft MVP, Visual C# My Articles
You wrote: Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists? The structure of the lists looks like that:
ClassA (objects are stored in SortedListA)
| |
| |----> reference to object of ClassB (objects are stored in SortedListB)
|
|--------> reference to object of ClassC (objects are stored in SortedListC)All classes contain only simple data types like strings, uints, floats, etc. Furthermore ClassA contains, as you can see in my amazing ASCII-diagram ;), a reference to an object of ClassB and a reference to an object of ClassC. Nothing more. So I think everything should be serializable. As I said in my first post, everything works fine until deserialization. Then the references seem to be independent objects. I can't manipulate the referenced objects through the reference. So perhaps the framework notices that I want to serialize a reference and since this is not possible cause addresses are shifting, the framework serializes just a copy of the referenced object. But because of these limitations I would prefer at least a warning while compiling or an exception at runtime... :( Regards, mYkel
-
You wrote: Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists? The structure of the lists looks like that:
ClassA (objects are stored in SortedListA)
| |
| |----> reference to object of ClassB (objects are stored in SortedListB)
|
|--------> reference to object of ClassC (objects are stored in SortedListC)All classes contain only simple data types like strings, uints, floats, etc. Furthermore ClassA contains, as you can see in my amazing ASCII-diagram ;), a reference to an object of ClassB and a reference to an object of ClassC. Nothing more. So I think everything should be serializable. As I said in my first post, everything works fine until deserialization. Then the references seem to be independent objects. I can't manipulate the referenced objects through the reference. So perhaps the framework notices that I want to serialize a reference and since this is not possible cause addresses are shifting, the framework serializes just a copy of the referenced object. But because of these limitations I would prefer at least a warning while compiling or an exception at runtime... :( Regards, mYkel
Which serialization are you using? The
System.Runtime.Serializationnamespace elements or theSystem.Xml.Serializationnamespace elements? The former does serialize references (as I mentioned before) but requires something to associate them with the original object. Since you don't have such a serialization manager, a copy of the class is deserialized, yes. There is not way to get an existing reference back since memory address shouldn't be stored (isn't durable), only to associate the data with existing objects. If you don't have something that will do that, all that can be returned is a copy of the class. Again, read the link I sent you for more information.Microsoft MVP, Visual C# My Articles