Deprecating the SoapFormatter

Now that I have your attention...

We are seriously considering deprecating the SoapFormatter in .NET Framework 2.0.  It is the nexus of a whole host of serialization issues and implies a promise of interop that it does not and will not live up to.  It also does not support generics.  Additionally, those of you interested in the new Version Tolerant Serialization features in .NF 2.0 will note that it is not supported on the SoapFormatter.  This means that types using VTS to introduce new fields would break when serializing between versions over the SoapFormatter.  This is also true for framework types.  So if you are using a framework type that adds fields in .NF 2.0 and you do not upgrade both apps using the SoapFormatter to .NF 2.0 then you could see serailization errors occuring simply by upgrading to .NF 2.0 on one side.  Before you ask, no I don't have a list of framework types that might break in this scenario but the question is whether requiring switching to the BinaryFormatter is unacceptable.

The obvious solution to this is to switch to the BinaryFormatter. It supports VTS, the serialization of generics and is one of the Cross-AppDomain formatters, where our guidance recommends the usage of .NET Remoting for new applications.

This is our stance as of Beta1 for .NET Framework 2.0.

So the questions is:  Who has to have the SoapFormatter in .NF 2.0 and why?

Comments

• Anonymous
  August 23, 2004
  The comment has been removed
• Anonymous
  August 23, 2004
  The comment has been removed
• Anonymous
  August 23, 2004
  Deprecating the SOAPFormatter in .NET 2.0
• Anonymous
  August 23, 2004
  Let it die. Good riddance.
• Anonymous
  August 23, 2004
  There are apps where the SoapFormatter is used in more like a convenient "object-tracking" scenario, the serialized SoapFormatter output is used to identify the object in a log or similar.
  
  Naturally, a soap XML string is at least in theory human-readable, while a binary formatted string simply isn't.
  
  (I wasn't responsible for the design, but I've seen it used in this way.)
• Anonymous
  August 23, 2004
  The comment has been removed
• Anonymous
  August 24, 2004
  Soapformatter could be deprecated in .Net 2.0 (Whidbey)
• Anonymous
  August 24, 2004
  The comment has been removed
• Anonymous
  August 24, 2004
  I have built and deployed a whole suite of products interfacing IBM's MQ Series to Microsoft over SOAP using this technology. Such a move essentially destroys my investment, and give great creedance to the open source argument.Every day I battle those folks who advocate open source. How do I maintain any credibility with my customers, if it appears that you willing to arbitrarily deimplement critical features.
  
  The time to make any decision deimplement this was back when you released 1.0, not after it has been deployed.
  
  Perhaps if you want to get out of this situarion for the long term, support it through 2.0, with the understanding that you will provide a clean migration path in some future release.
  
  To be clear, the move you are contemplating would go a long way toward driving me out of business.
  
  Given the alternatives, I would consider assisting you in developing a migration path/strategy, but I need more time than a 2.0 deimplementation would provide.
  
  If you are interested in my assistance on thsi matter, I can be reached at (949)733-0641 or alternately at dbrenner@stahurabrenner.com
  
  
• Anonymous
  August 24, 2004
  Please deprecate it!!!
• Anonymous
  August 24, 2004
  They are deprecating the SoapFormatter.  I don't think I have to have it anymor...
• Anonymous
  April 03, 2006
  PingBack from http://stefano.killerblog.net/DetailsView.aspx?PostingID=162daf4f-aaca-444f-b79b-ec2e8bbebde4
• Anonymous
  May 14, 2006
  <doc><div xmlns="http://www.w3.org/1999/xhtml" style="PADDING-RIGHT: 0in; MARGIN
• Anonymous
  January 28, 2008
  PingBack from http://blog.getpaint.net/2008/01/28/paintnet-is-going-to-get-8-bit-and-24-bit-png-support/