I have tested the dataset new "binary serialize" feature in ADO.Net
2.0. Many articals said if we set the dataset's property
"RemotingFormat" as "SerializationFormat.Binary", it can serialize
itself in binary format.
OK, this propety works well, the output file is much smaller than xml style.
But i got something strange:
If
i first set a dataset "RemotingFormat" as "binary" before serialize it
into a file, then Deserialize it to a new dataset , the new dataset's
"RemotingFormat" value is missing, it become the default value:
"XML"!!!
FileStream fs = new FileStream(System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "ds.dat", FileMode.OpenOrCreate);
DataSet ds = GiveMeFakeData();
ds.RemotingFormat = SerializationFormat.Binary;
bf.Serialize(fs, ds);
fs.Close();
// Check the deserialization performance.
fs = new FileStream(System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "ds.dat", FileMode.Open);
long nowticks = DateTime.Now.Ticks;
DataSet ds2 = (DataSet)bf.Deserialize(fs);
//note here!
//ds2.RemotingFormat == SerializationFormat.XML!
long tickstotal = DateTime.Now.Ticks - nowticks;
Console.WriteLine("Took me : " + tickstotal);
fs.Close();
Then i dig into the source code, i have found
{
info.AddValue("DataSet.DataSetName", this.DataSetName);
info.AddValue("DataSet.Namespace", this.Namespace);
info.AddValue("DataSet.Prefix", this.Prefix);
info.AddValue("DataSet.CaseSensitive", this.CaseSensitive);
info.AddValue("DataSet.LocaleLCID", this.Locale.LCID);
info.AddValue("DataSet.EnforceConstraints", this.EnforceConstraints);
info.AddValue("DataSet.ExtendedProperties", this.ExtendedProperties);
}
It looks like the dataset didn't serialize the RemotingFormat Property.
Anyone knows why it like this? Is it a bug or a design decision?
(have reported this issue to MS)
Updated: 2005/9/26
The ADO.net PM (Kawarjit Bedi) has replied this issue:
=== QUOTE ===
The primary motivation for doing that were:
1. Backward
compatibility. If a v2.0 client recives DataSet from v2.0 server using
BinaryRemoting (set at server side - the client does not know it) and
then sends the same DataSet to v1.x client without resetting the
RemotingFormat property to XML, it'd break the v1.x client. With the
default behavior, it'd not break this case.
2. The value of
RemotingFormat property is a like a parameter being passed to the
remoting engine, it's more to do with the remoting operation then the
DataSet's state, hence the reluctance to serialize the property.
=== END QUOTE ===
So, this is not a bug but a design decision.
Thanks Kawarjit :)