Какие данные передаются в Сериализации? (Двоичная Сериализация)

Двоичная сериализация - это моментальная съемка объекта и его сериализация. Это означает, что все частные поля, которые не помечены как NonSerializable, будут сериализованы со своими значениями. Все объекты, используемые в иерархии объектов, должны быть сделаны как сериализуемые. Вы должны поместить атрибут [field: NonSerializable] в события, чтобы обработчики событий тоже не сериализовались: http://bytes.com/groups/net-c/250944-nonserialized-attribute-events#post1013968

Имейте в виду, что при десериализации объекта у вас должен быть точно такой же объект в той же сборке, что и при его сериализации (то же самое означает та же информация о сборке). Если нет, вы можете использовать класс SerializationBinder, чтобы вы могли сбросить тип, в котором поток будет стерилизован.

По умолчанию, при использовании двоичной сериализации сериализуются только поля определенного типа. Свойства обрабатываются как методы и не влияют на сериализацию.

При использовании Xml-сериализации общедоступные свойства сериализуются по умолчанию.

I assume you mean BinaryFormatter; it depends ;-p

The purpose of serialization is to express a complex in-memory object as a simple sequence of bytes (or depending on the serializer - characters, etc) that can be re-hydrated at the other end to re-create the object.

Some types (primitives, strings, etc) have inbuilt direct support by the serializer - it writes these directly.

In the case of classes, the type metadata (incuding assembly name etc) is written, then all of the fields on the type are enumerated (essentially, Type.GetFields(), including private etc). For every field (not marked [NonSerialized]), the field name is written, and the value is serialized (through the same process). Eventually, everything boils down to the inbuilt primitives, some type definitions, and some name/value field pairs.

An exception here is if the type implements ISerializable - in which case the type is asked to serialize itself to the output. This is common in things like dictionary types, where the in-memory layout of the type can be expressed differently to a stream.

During deserialization the process is reversed; the type-metadata is used to create an empty object (unless it has a special serialization constructor/ISerializable); then the fields are set as they are found in the stream.

In both serialization and deserialization there are "callback" points where you can execute additional code to fix-up objects for (de)serialization.

This process is brittle; for lots of reasons, see here - but it is also version intolerant and implementation specific (you can't consume it from java etc).

protobuf-net solves a lot of these problems, by being a binary serializer that is contract-based, rather than field-based.