It depends. XmlSerializer has severe limitations such as the requirement thatthe target class has a parameterless constructor, and only public read/write
properties and fields can be serialized. However, on the plus side,
XmlSerializer has good support for customising the XML document that is
produced or consumed. XmlSerializer’s features mean that it is most suitable
for cross-platform work, or for constructing objects from existing XML
documents.
SoapFormatter and BinaryFormatter have fewer limitations than
XmlSerializer. They can serialize private fields, for example. However they
both require that the target class be marked with the [Serializable] attribute,
so like XmlSerializer the class needs to be written with serialization in mind.
Also there are some quirks to watch out for – for example on deserialization
the constructor of the new object is not invoked.
The choice between SoapFormatter and BinaryFormatter depends on the
application. BinaryFormatter makes sense where both serialization and
deserialization will be performed on the .NET platform and where
performance is important. SoapFormatter generally makes more sense in all
other cases, for ease of debugging if nothing else.