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.

  • 1
    – Ewan
    Jul 13, 2018 at 14:53
  • I want to review any type a remote party can instantiate for its security impact before allowing an attacker access to them. Jul 13, 2018 at 14:53
  • 3
    Because only academics and questions on Stack Overflow care about LSP.
    – user949300
    Jul 13, 2018 at 15:23
  • @user949300 You made my day... hahahaha Jul 13, 2018 at 16:37

1 Answer 1


My understanding is that this is a problem of deserialising the xml to actual concrete classes.

The WCF client needs to instantiate the same class, or at least a class with the same public properties, as the class which was sent from the server.

This poses a problem when a derived class is used in place of the class or interface specified as the method return type.

Using the KnownType and ServiceKnownType attributes cause the KnowTypes to be included in the WSDL and enables returned objects to be deserialised to the correct type.

Why not send the class information when the new class is sent?

One of the key things with WCF is being able to publish all the information required to consume the service. This allows A client is able to self generate from the WSDL with its own version of the classes. Considered an important aspect of the architecture, although often avoided with the 'use locally known classes' options

But this requires that all the possible classes are known up front. If you dynamically sent a new class not included in the WDSL the client would be forced to represent the base class as dynamic or some such and not know what Properties might be included at runtime.

Why not analyse the code base to determine all possible subtypes rather than use attributes

Leaving aside complications caused by loading types at runtime, this should be possible. However, WCF makes extensive use of attributes, as do other MS technologies of the time. Does it really make a difference to the LSP whether an attribute must be added by hand or whether it is added automatically by a precompilation step?

  • It is clear to me that also the concrete classes sent over the web most be known on the other side also. I do not remember the details of .Net Remoting, I think there it was not necessary to declare all possibly used concrete types in the contract (and that's the point: having to declare them in the contract). Jul 13, 2018 at 14:45
  • 1
    @BernhardHiller: Let's say you get a clear answer about this question, maybe even from some expert at Microsoft who actually talked to Liskov herself. What then? Will it change the way you use WCF? Jul 13, 2018 at 14:47
  • 1
    – Ewan
    Jul 13, 2018 at 14:49
  • looks like the answer there gives you a good get around and explains the whys and wherefors
    – Ewan
    Jul 13, 2018 at 14:50
  • @Ewan: That's pretty cool. Jul 13, 2018 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.