Not that I'm a big SOAP fan, but the author seems to be seriously confused: "For starters you have to point Visual Studio (sigh) to the service reference, at w

Not that I'm a big SOAP fan, but the author seems to be seriously confused: "For starters you have to point Visual Studio (sigh) to the service reference, at which point nine thousand (yes, that’s nine-zero-zero-zero) lines of code are generated." "Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.”" "Long story short, in order to inspect SOAP messages you have to write a class that implements the ICLientMessageInspector interface." These are supposed to be problems with SOAP? To me they look like a crappy implementation. The conclusion is also crappy: "In my mind SOAP’s biggest failure is what some people consider to be its biggest success – it abstracts away all notion of the underlying HTTP model and replaces it with crutches like code generation." Jeez, man - SOAP has problems, but code generation!? It's not a problem with SOAP but with the way your environment integrates with SOAP. Code generation over any protocol would create the same problems and there's nothing about SOAP that makes code gen inevitable.