CODEWITHSUNDEEP
c#wcf.net-coremetadatadatacontract
Zed
Zed

Reputation: 1

Error occurred while deserialize parameter http:tempuri.org/:

I am Getting error while calling a WCF service via service proxy : Type [mytype]'1[system.collection.generic.list'1] cannot be added to list of known types since another type [mytype'1] with same data contract is already present.

Any idea how to resolve that ??

Coming after I have run svcutil for same host two times i.e. first time default (Array) and second time with adding /ct: parameter to generate with list type.

Upvotes: 0

Views: 258

Answers (1)

Sergey A Kryukov
Sergey A Kryukov

Reputation: 629

This is a simple problem related to naming conventions.

You can see in the XML files that the type names, where required, are represented in XML as simple names, without, say, C# namespaces. Instead, namespaces declared by the [DataContract] attributes are used. Please see DataContractAttribute.Namespace Property.

Let's say, you use only one unique namespace string for the entire data contract. Then the namespace appears only once in the XML, as a namespace of your root data graph object. The identities of the types are represented not by different namespaces, but by data contract namespaces. This is a very wise feature: you can freely change namespaces in your source code and qualified names accordingly, without breaking the contract. You can also use different data contract namespaces in your data contracts, but then the namespaces other than the one of the object graph root will appear in XML.

The only problem with that naming appears in the case of a name clash that the data contract technology cannot resolve. Your exception information demonstrates one of such cases. How come two different types have the same name mytype? This can happen, for example, because they have different qualified names, that is, different namespace names. This is fine from the programming standpoint, but the data contract mechanism cannot resolve that clash.

To resolve this clash, you can either

  1. Make all simple names of all types participating in the same data contract distinct, or
  2. Use more than one data contract namespace string. In this case, one of the two types with an identical simple name should have one data contract namespace, prescribed in its [DataContract] attribute, and another one — a different namespace.

I would strongly prefer the solution #1 whenever possible — things should not be more complicated than necessary.

Note that the problem manifested by your exception is also related to known types used to deal with polymorphism. The data contract mechanism needs to know the set of possible runtime types derived from a polymorphic (abstract or not) base class participating in a data contract or implementing some common interface. Each of those runtime types should be a part of the data contract and meet all the data contract requirements — this is another rule you have to observe.

Upvotes: 0

Related Questions