Why .Net Remoting doesn't need known types but WCF does?

Question

We are migrating our .net Remoting app to use WCF. One thing that confuses me now is the concept of "Known types" that WCF introduced but not needed by Remoting. While I am sort of understand what the known types are and what they do, what I am confused about is the difference between WCF and Remoting - On the sender's side, if WCF doesn't have enough type information about the object at hand to serialize it, why does Remoting? Same for the receiver: Why .net Remoting doesn't have a problem deserializing an object received but WCF does? Is that because Remoting sends metadata along with the data? If so why can't WCF do the same?

Answer 1

You're correct - .NET remoting sends type metadata with the requests. WCF can do the same, but by default it doesn't - it's a lot of extra information which makes the requests larger and more complex to process (affecting performance). Not sending the type information also allows for loosely coupled systems, where the client and the server can version separately, and as long as they adhere to the contracts established in the original version, they will continue working. And it also allows for WCF to talk to systems written in non-NET platforms (which isn't possible with remoting or other technologies which rely on shared type information).

If you really want to go with the non-known-types way, you can replace the default serializer used by WCF (the DataContractSerializer) with the NetDataContractSerializer, which will send type information with each request. To use that, search for "wcf netdatacontractserializer" and you'll find how to use it.