More Reasons to Not use ASMX Services in New Code

Many people continue to use ASMX web services despite my earlier post “Microsoft says: ASMX Web Services are a “Legacy Technology”” and other such warnings. This is, of course, a matter of personal preference. Here are some of the many reasons why I personally prefer not to use ASMX services for new development:

  1. ASMX web services are Microsoft’s first attempt at web services. They were a good start – they showed us why we need WCF.
  2. There are very few extensibility points.
  3. ASMX supports only SOAP 1.1 and 1.2, and can be coerced into returning JSON for JavaScript support. WCF supports those features plus everything else.
  4. ASMX can only be  hosted in IIS
  5. No support for any of the WS-* standards
  6. Again, ASMX Web Services are a “Legacy Technology”
  7. They are based on the old XML Serialization technology, which is not getting bug fixes. (see Microsoft comment on 1/11/2010)
  8. only proactively fixing the most critical customer impactful issues in XmlSerializer and xsd.exe, which are the technologies on which the SOAP support of ASMX services are based (see Microsoft comment on10/1/2008)
  9. no longer making enhancements to ASMX (see Microsoft comment on 6/29/2009 7:09 PM)

Whenever I’m asked, I recommend requiring that any new code deployed into a Production environment should be based on technology that is supported by the vendor. To me, this isn’t a simple matter of whether the code is on the vendor’s “supported” list. After all, ASMX is part of .NET 2.0, which is still supported. To me, it’s a question of, “if this technology breaks in my Production environment, can I count on the vendor fixing the bug”. In the case of ASMX web services and their underlying XML Serialization technology, the answer is, “no”.

As the links above demonstrate, we can count on Microsoft not fixing such bugs


7. Posted by Microsoft on 1/11/2010 at 11:34 PM

We have confirmed that the inherited properties do not show up in SOAP Sample on the browser and that is indeed a bug in the product.
At this point, this area is in maintainance (sic) mode, and no active work is planned.
thank you for reporting it.

8. Posted by Microsoft on 10/1/2008 at 10:10 AM

Thanks for finding this. We have investigated the issue and it is a bug. A workaround is to modify the generated schema to trick the code generation logic to not generate the multi-dimensional array. You can do this by adding a dummy attribute to the schema type. Unfortunately, we’re only proactively fixing the most critical customer impactful issues in XmlSerializer and xsd.exe. If this issue is causing business impact please contact Microsoft Product Support Services and we will be happy to explore various options.
Ed Pinto

9. Posted by Microsoft on 6/29/2009 at 7:09 PM

We’re no longer making enhancements to ASMX; we continue to support its existing functionality, but where possible, we recommend using WCF instead.

This entry was posted in ASMX, Web Services, XML Serialization. Bookmark the permalink.

3 Responses to More Reasons to Not use ASMX Services in New Code

  1. Nery R. Gonzalez says:

    What should we use instead?

    • WCF should be used instead, if you need SOAP services. Otherwise, ASP.NET Web API is becoming more popular for purely REST-based services. Of course, WCF can do both. In fact, with WCF, you can create one service and expose it both as REST and as SOAP.

  2. Does this mean all [WebMethod] and [ScriptMethod] should be avoided? Or only when they’re used in an ASMX service?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s