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"!!! 

   BinaryFormatter bf = new BinaryFormatter();
   FileStream fs 
= new FileStream(System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "ds.dat", FileMode.OpenOrCreate);
   DataSet ds 
= GiveMeFakeData();
= SerializationFormat.Binary;
   bf.Serialize(fs, ds);

// 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;
"Took me : " + tickstotal);

Then i dig into the source code, i have found  

 private void SerializeDataSetProperties(SerializationInfo info, StreamingContext context)

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 :)