When you want to send your own types over WCF, you have to add lots of [ServiceKnownType(typeof(MyFirstConcreteType))]
to the interface definition of your contract.
You cannot use [ServiceKnownType(typeof(IMyInterface))]
instead though that will compile, and then fail at runtime.
Also when defining MyExtendedFirstConcreteType : MyFirstConcreteType
, you have to add an extra [ServiceKnownType(typeof(MyExtendedFirstConcreteType))]
.
That is a clear violation of the Liskov Substitution Principle, because you cannot use a derived type where you can use the base type.
Why was WCF designed with this flaw? Are there good workarounds available?
While such questions are irrelevant for code monkeys, a software architect should understand the technologies he chooses, know their advantages and disadvantages, and apply that knowledge to the project. A team leader could use that input from the architect in order to find out if there are enough team members with a sufficient knowledge of those technologies, and perhaps estimate costs of training and introduction vs. staying with a technology the team is experienced in. People in Quality department might be upset to hear that run-time error could appear which can hardly be prevented by automated testing methods - the architect might need some good reason why he would accept that. Etc.