Well, anything that existed already in earlier versions of .NET is fine; they've usually just kept the same documentation. However, anything to do with MVC (3 or 5 etc.) or any other new component in .NET 4.5 is what Joel Spolsky (?) called "undocumentation," that is, documentation in the format DoThing(); // Does the thing That's not an explanation; it's just a rearrangement of the function name.

Ha, that is so funny. t must be a spoof post. In any case, I couldnt help responding sarcasticly! Morality is indistinguishable from social proscription

Regardless, the serialization method you use will significantly effect the size of the payload sent over the wire. DataContractSerialization is simiar to XMLSerialization. You stated you were comparing WCF with HTTPBinding to .Net Remoting. The size of the payload will significanly impact the time it takes to transmit over the wire. This has two problems: 1. By default, .Net remoting uses Binary Serialization. Binary Serialization produces much smaller payloads than DataContract Serialization. The NetDataContractSerializer will produce payloads similar in size to BinarySerialization. 2. .Net Remoting is a connection protocol, whereas HTTPBinding is connectionless. Why is this important? Each time you make a method call in WCF/HTTPBinding it will reconnect to the server. In .Net remoting, this is not the case -- the port remains connected. Hence reconnecting for each method call is expensive. Using WCF / net.tcp will eliminate this difference. Unless the call throws an exception, in which case you must close and reconnect. Hence due to these two reasons, when comparing .Net Remoting and WCF / HTTPBinding you can not reasonably expect similar timings.

Deleting Response.Close() in my code and moving the code to override the page render command fixed the issue. Why this would only show up on some servers I can't say.