Deprecating the Soap Formatter

The Soap Formatter is on the path of deprecation. Starting in v2.0 of the framework the usefulness of the soap formatter would be highly limited since it will not support some of the new v2.0 framework features such as generics and the version tolerant serialization programming model. An alternative would be to look at System.Xml.Serialization namespace. BinaryFormatter continues to be supported and does include functionality to support generics and VTS. Please send any available feedback if this would be a cause of concern.

Comments (4)
  1. Tom Guinther says:

    I think it is a shame that the SOAP formatter is not going to be orthoganal to the binary formatter. I will admit I am not a big fan of the SOAP formatter for most scenarios but from a tool/library developers perspective it is nice that my "end-user" can choose which formatter is right for their application.

    There is definitely something to be said about ‘not caring’ which formatter you are using and/or being able to switch them on the fly, but in the end, maybe the changes will be mostly transparent anyway.


  2. ManishG says:

    Thanks for your feedback Tom, we dont expect it to break in most cases.

  3. says:

    I just wanted to add one thing that is beneficial about the SOAP formatter and why I ocasionally recommend that people use it.

    The binary formatter is opaque, and for the average user, writing a ‘decompiler’ for analyzing or debugging serialized objects or messages is out of the question. In many cases I suggest (or provide) DualFormatter which implements IFormatter and automatically serializes to both binary and SOAP concurrently. This allows message streams or the contents of complex serialization streams to be debugged in a (almost) human readable format.

    This can be really important when dealing with versioning issues.

Comments are closed.

Skip to main content