K
klem s
I've already posted three replies in thread
http://groups.google.com/group/micr...f/9b86ae44cd3cd361?hl=en#9b86ae44cd3cd361,but
for some reason google groups doesn't display them. So I’ve decided to
instead start a new thread, which is basically just a continuation of
a before mentioned thread
about how dependencies are stored when serializing via
BinaryFormatter. Knowing that, is my assumption about how dependencies
are Serialized via BinaryFormatter more or less correct?
I already knew all of that
. What I was pointing out is that Derived
class is a child of Base class, but this parent child relationship
isn’t recorded in xml. Thus, just by looking at resulting xml one
would never figure out that Derived is child of a Base.
BTW - I realize I was wrong when suggesting we should create
subelement A to indicate parent child relationship, since subelements
indicate members of Derived and not parents/children – I had one of my
brain fart episodes and as such wasn’t thinking clearly
thank you
http://groups.google.com/group/micr...f/9b86ae44cd3cd361?hl=en#9b86ae44cd3cd361,but
for some reason google groups doesn't display them. So I’ve decided to
instead start a new thread, which is basically just a continuation of
a before mentioned thread
I should be more specific in my post, but I was actually asking moreI don't think you are quite getting my precise point.
about how dependencies are stored when serializing via
BinaryFormatter. Knowing that, is my assumption about how dependencies
are Serialized via BinaryFormatter more or less correct?
I understand your point that with some effort we can also serialize
into xml relationships between objects, but I assume in next example
XmlSerializer doesn’t store the parent-child relationship, since no
sub-element is created for type A:XmlSerializer xmlFormat = new XmlSerializer ( typeof( B ),
new Type[] { typeof( A ), typeof( D ) } )class A{}
class B:A { D d = new D(): }
class D{}
You assume incorrectly.
First, you need to understand that the class A is not a child of the
class B. Thus, there is no parent/child relationship to emit.
Second, if in your example the class B _did_ have a public member
referencing a child object, XmlSerializer would in fact emit that child
object as part of the serialized data, by representing it as a nested
element within the XML.
For example:
using System;
using System.IO;
using System.Xml.Serialization;
namespace TestXmlSerializer
{
public class Base
{
public int baseInt = 31;
}
public class Derived : Base
{
public Other other = new Other();
}
public class Other
{
public int i = 17;
}
class Program
{
static void Main(string[] args)
{
XmlSerializer serializer = new XmlSerializer(typeof(Derived));
using (StringWriter writer = new StringWriter())
{
serializer.Serialize(writer, new Derived());
Console.WriteLine(writer.ToString());
}
Console.ReadLine();
}
}
}
That code emits the following XML:
<?xml version="1.0" encoding="utf-16"?>
<Derived xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<baseInt>31</baseInt>
<other>
<i>17</i>
</other>
</Derived>
Note that the instance of the Other class, in the field "other", is
included as a nested element of the Derived object. Note also that the
public member in the base class A is emitted, not as a child of the
"Derived" element, but simply as a normal member of the "Derived"
element, just as it is in the language object model.
I already knew all of that
![Smile :) :)](/styles/default/custom/smilies/smile.gif)
class is a child of Base class, but this parent child relationship
isn’t recorded in xml. Thus, just by looking at resulting xml one
would never figure out that Derived is child of a Base.
BTW - I realize I was wrong when suggesting we should create
subelement A to indicate parent child relationship, since subelements
indicate members of Derived and not parents/children – I had one of my
brain fart episodes and as such wasn’t thinking clearly
thank you