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 (30)

  1. Brad says:

    Kill it. Here’s why … if "implies a promise of interop that it does not and will not live up to". If there were a trade available between interoperability and bandwidth, I think it might be different, but there isn’t, so time to play taps.

  2. Deprecating the SOAPFormatter in .NET 2.0

  3. cn says:

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

  4. Paul Gibson says:

    By "deprecate" I assume you mean that any existing 1.1 code using the SoapFormatter which runs today will run on 2.0 but can’t use new features (such as serializing generics)?

    My app uses the SoapFormatter extensively to serialize complex object graphs and store them in a database. We chose the SoapFormatter because ironically it seemed more "future proof" (since if a meteor struck Redmond and the Binary formatter became lost we could at least have some xml to parse). We did have to end up implementing the ISerializable interface to allow for new members getting added across versions in our app and that is working today, although I was looking forward to getting this for free in .Net 2.0.

    In hindsight I now realize that these formatters were probably better suited for transient serialization scenarios such as remoting rather than stuffing stuff in a database to be re-hydrated later on possibly later versions of code. If I could go back I’d probably switch over to the System.XML stack for this kind of serialization. Of course we’d have to solve the object graph problem in that case.

    The bottom line for my company’s application is that if the SoapFormatter does not have feature parity with the BinaryFormatter then it will mean that we will either have to forego any 2.0 features in our serialized classes or undergo an exensive conversion process on this part of the data in our customer’s databases. At a minimum I would expect that my existing ISerializable code would still work on the SoapFormatter, and ideally I would at least be able to manually be able to deal with generic members.

  5. Sahil Malik says:

    Soapformatter could be deprecated in .Net 2.0 (Whidbey)

  6. Sahil Malik says:

    Deprecating the Soapformatter sounds fairly radical. I use the Soapformatter to view an english-text friendly view of my serialization, just to make sure it is working as I had expected it to. Now I will have to write my own formatter – which isn’t such a big deal but is extra work. Not to mention the scores of webservices out there which insist on using Soapformatter for XML compatibility – the reasons might not be very justified but the bottom line is that I received a webservice spec yesterday where the vendor cannot be convinced not to use Soapformatter over the internet – and hey, I have to live with it.

    Version tolerant serialization can be acheived by implementing your own ISerializable, but I agree it is more of a hack than a neat and clean method of doing it. (If I really understood what you meant by VT Ser). But yes, I would *love* to see VTS in .NF 2.0.

    I’m not a huge fan of Soapformatter given it’s bloat, and I guess eventually it makes sense to wean folks away from it, but for now, I have no emoticon to express the pain that I feel coming due to that.

    But then again, .NET is hitting puberty and with puberty come weird inexplicable problems. We’re gonna have legacy .NET code already :-/

    I’ve put a discussion on this in my blog too

    http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/08/24/23068.aspx

  7. Dale Brenner says:

    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

  8. They are deprecating the SoapFormatter.  I don’t think I have to have it anymor…

  9. <doc><div xmlns="http://www.w3.org/1999/xhtml" style="PADDING-RIGHT: 0in; MARGIN

Skip to main content