Serialization error when property is declared as base class, but populated by derived class

I’ve receive  quite generic error Message :
 Type ‘MyclassType’ with data contract name ‘MyclassType:’ is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
Type : System.Runtime.Serialization.SerializationException, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

After investigation I found that the class that I tried to serialize, had a property declared of the base class, but at runtime derived class was assigned, and serialization was unable to resolve it.
The fix was simple- to add KnownType property to container class.

public class Mycontainer 
 MyBaseclass PropertyOfmyClass { get; set;}

public class  MyclassType : MyBaseclass
{ ….}

Unfortunately, the serialization time error message didn’t specify the name of container class , not the name of property. it makes harder to fix the error.

Response for REST method was truncated because default MaxItemsInObjectGraph was not big enough.

We have a   REST service with attributes [WebGet(UriTemplate =“…”, BodyStyle =WebMessageBodyStyle.Bare, ResponseFormat =WebMessageFormat.Xml)]

Normally it worked fine. But for particular data it has a huge response that was truncated. 

The size returned in a few attempts in IE browser was 2196456, in Chrome slightly different 2195397.

After a search in google I found, that has a number of suggestions.


For WCF service that will transfer large amount of data in operations, here are the configuration settings you need to check:

1) the maxReceivedMessageSize attribute of the certain <binding> element(in your case, that’s the webHttpbinding)


2) The <readerQuotas> settings (under the <binding> elements) which has control over the maxarrayLength, maxStringLength ,etc…


3) The DataContractSerializer behavior which has a MaxItemsInObjectGraph property. You can configure it via ServiceBehavior of your WCF service

#DataContractSerializer.MaxItemsInObjectGraph Property

4) And if your WCF service is hosted in ASP.NET/IIS web application, you also need to enlarge the “maxRequestLength” attribute of the <httpRuntime> element (under <system.web> section).

#httpRuntime Element (ASP.NET Settings Schema)

 After a few attempts my collegue found that our problem was caused by

#DataContractSerializer.MaxItemsInObjectGraph Property


<behavior name=“MyOperationBehavior>
          < dataContractSerializer maxItemsInObjectGraph =2196456 />

WCF Transactions are not supported by Azure.

We have a service operation, for which it is very important to ensure that a client receives the status, that was determined at the end of operation.
If client does receive the response, the server status should be “completed”. Otherwise (in case of communication error), server status should be rollback and stay as “pending”. The possible technical solutions were discussed and WCF Transactions support with  2PC(two phase commit) was selected.  We implemented service operation with transaction commit/rollback support and asked our clients to use it.
Our main client is running on Azure. It was a big disappointment, when Readify consultant Himanshu Desai  adviced that WCF Transactions are not supported by Azure.
I did a quick check on Internet and didn’t find that is well known issue.
Below are a few quotes to describe the limitation:

2PC in the cloud is hard for  all sorts of reasons. 2PC as implemented by DTC effectively depends on the coordinator and its log and connectivity to the coordinator to be very highly available. It also depends on all parties cooperating on a positive outcome in an expedient fashion. To that end, you need to run DTC in a failover cluster, because it’s the Achilles heel of the whole system and any transaction depends on DTC clearing it.

The bottom line is that Service Bus, specifically with its de-duplication features for sending and with its reliable delivery support using Peek-Lock (which we didn’t discuss in the thread, but see here and also here) is a great tool to compensate for the lack of coordinator support in the cloud

The Azure storage folks implement their clusters in a very particular way to provide highly-scalable, highly-available, and strongly consistent storage – and they are using a quorum based protocol (Paxos) rather than classic atomic TX protocol to reach consensus. 

In the current release, only one top level messaging entity, such as a queue or topic can participate in a transaction, and the transaction cannot include any other transaction resource managers, making transactions spanning a messaging entity and a database not possible.

Has Windows Azure any kind of distributed transaction mechanism in order to include any remote object creation in an atomic transaction including other domain-specific operations?  
The alternative solution suggested by Himanshu Desai is to have an operation to start a process on the server and then poll in a loop on a client until final status is received from the server. 


maxItemsInObjectGraph limit required to be changed for server and client

We have a wcf service, that expects to return a huge XML data. It worked ok in testing, but in production it failed with error  "Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota."

The MSDN article about   dataContractSerializer xml configuration  element  correctly  describes maxItemsInObjectGraph attribute default as 65536, but documentation for of the 

DataContractSerializer.MaxItemsInObjectGraph property and DataContractJsonSerializer.MaxItemsInObjectGraph Property 

are talking about Int32.MaxValue, which causes confusion, in particular because Google shows properties articles before configuration articles.

When we changed the value in WCF service configuration, it didn’t help, because the similar change must be ALSO done on client.

There are similar posts:
You need to set the MaxItemsInObjectGraph on the dataContractSerializer using a behavior on both the client and service. See  for an example.
 I had forgot to place this setting in my client app.config file.
It seems that DataContractJsonSerializer.MaxItemsInObjectGraph has actual default 65536, because there is no configuration for JSON serializer, but  it complains about the limit.

I believe that MS should clarify the properties documentation re default limit and make more specific error messages to distinguish server side and client side errors.
Note, that as a workaround it’s possible to use commonBehaviors section which can be defined only in machine.config:
<dataContractSerializer maxItemsInObjectGraph="..." />


Using interfaces in DataContracts for WCF service versioning.

We are implementing WCF Service versioning after having problems  with enums in response  (  Do not expose enum in WCF response )
I found that we need rigorously follow the recommendations “Versioning When Schema Validation Is Not Required” from msdn article:
Best Practices: Data Contract Versioning

Initially I’ve ignored the recommendation “Do not attempt to version data contracts by type inheritance” and failed to generate backward compatible XML.

Reading the documentation I’ve noticed in Service Versioning article
an example
public interface IPurchaseOrderV2
   DateTime OrderDate { get; set; }
which includes only one new field. It is used in

Name = “PurchaseOrder “,
Namespace = “”)]
public class PurchaseOrderV2 : IPurchaseOrderV1, IPurchaseOrderV2
   public DateTime OrderId {…}
   public string CustomerId {…}
   public DateTime OrderDate { … }

I believe that it would it be more appropriate to have IPurchaseOrderV2 derived from IPurchaseOrderV1.

public interface IPurchaseOrderV2: PurchaseOrderV1
   DateTime OrderDate { get; set; }

I asked myself,  should I repeat all properties from original in a new interface and would it give any benefits to versioning.

public   interface IPurchaseOrderV2  
   public DateTime OrderId { get; set; }
   public string CustomerId { get; set; }
   public DateTime OrderDate { get; set; }
but I was on a wrong track.
Interface is not allowed to be marked as DataContract.The reason is explained in  the answer of

XML schema doesn’t know anything about interfaces – it’s all about concrete, actual types.

Using interfaces for service contracts are recommended, however  interfaces in dataContracts are not exposed externally.
i’ve checked the article again and found that the appendix  in MSDN  actually is quite clear:
write INTERNAL implementation code in terms of the interfaces rather than the data contract classes that implement the interfaces.
I just confused myself by quick browsing instead of proper reading.

ResolveUrl() from WCF service

I wanted to ResolveUrl() from WCF service and found .
However the function assumes that the call is synchronous, in asynchronous call (e.g called from TPL task) HttpContext.Current==null.
I had to split my asynchronous method into two-a long asynchronous one, invoked as task and generating relative URL and a post-task, that is calling wwWebUtils.ResolveServerUrl(relativeUrL)

The  article suggests to use
but i expect, it wouldn’t work from asynchronous thread as well.

Do not expose enum in WCF response

We had a backward compatibility problem in WCF client, when in Service application a new value was added to one of enums. We discussed different ways to avoid this backward compatibility issues, and I found recommendation do not expose enum in wcf response in

It is still required to create new versions of our service interfaces to replace each enum fields with string field, that expects only documented values, and describe, what should be default behavior, if field has an unexpected value.


As a workaround for backward- compatibility of enums, they can be declared as [DataContract] and only old values set as [DataMember] , but left new values without the attribute until the new MAJOR release.Members that are not marked are not serialized.  See Enumeration Types in Data Contracts.

Custom HTTP response header to identify server in a farm.

We wanted to follow recommendation from to

“add “From” header and set the server name. I do this on each webserver and specify different names on each box. It’s handy to see from which servers requests are being served. When you are trying to troubleshoot load balancing issues, it comes handy to see if a particular server is sending requests”


However one of the client of our rest service reported that From value in the response header is not valid and causing the .net HttpClient to throw an exception.

Innermost Message: The header cannot be added. Make sure to add request headers to HttpRequestMessage, response headers to HttpResponseMessage, and content headers to HttpContent objects.

Innermost Source: Microsoft.Net.Http

Innermost StackTrace: at System.Net.Http.Headers.HttpHeaders.CheckHeaderName(String name)

  at System.Net.Http.Headers.HttpHeaders.AddWithoutValidation(String name, String value)

  at System.Net.Http.HttpClientChannel.AddHeaderValues(WebHeaderCollection source, Int32 index, String header, HttpHeaders destination)

  at System.Net.Http.HttpClientChannel.CreateResponseMessage(HttpWebResponse webResponse, HttpRequestMessage request)

  at System.Net.Http.HttpClientChannel.GetResponseCallback(IAsyncResult ar)

HTTP/1.1 200 OK

Date: Fri, 09 Mar 2012 07:29:25 GMT

Server: Microsoft-IIS/6.0


According to

The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by “mailbox” in RFC 822 [9] as updated by RFC 1123 [8]:


      From   = “From” “:” mailbox

An example is:       From:

This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.

Actually standard doesn’t specify From as expected RESPONSE header(only as request).
however we should rename the custom header to something else to avoid conflicts, e.g.

FromServer: FARMSRV04

Make WCF services to help use the same namespace when called from WCF Clients

We have two services, that can be called independently, but also can be used together. They have some common types, and if they called together, default Visual Studio proxy generation will create the same types in different namespaces.
There are multiple articles, that recommend to use command line SvcUtil instead of Visual Studio IDE.
The article How to reuse types across service endpoints suggests on client side manually update Reference.svcmap to include multiple <MetadataSources> and NamespaceMappings
Alternatively svcutil does allow you to specify multiple endpoints at a single time and utilize /r(/reference)  and /n(/namespace) parameters
.Another commonly discussing solution is to  Share Types Between WCF Service and Client., but client not always has access to served data types.

If you are writing services and wish to simplify coding by your clients, consider to create additional “wrapper” service, that will include implementations of both interfaces, that are implemented by original services.
The approach is mentioned in  Generating Proxy class file for webservices with sharing TYPES and Meineck.Net: WCF: Hosting multiple WCF services as one single service.
Note that wrapper service will describe methods from both services, but the actual methods are trivial- just redirect to individual services implementation.

Use WCF Binary Encoding when Host in IIS6

I wanted to replace .Net Remoting calls with WCF.

Article From .NET Remoting to the Windows Communication Foundation (WCF)was very useful for me. It was misleading reference to Attribute ReturnUnknownExceptionsAsFaults which doesn’t exist any more.It has been changed to IncludeExceptionDetailInFaults,

I wanted to use WCF Binary Encoding when Host in Windows 2003 Server(IIS6) instead of text encoding, that is coming out-of-the-box
I found the blog WCF: Enable Binary Encoding Over Http
and literally copied custom binding settings from the blog
<binding name=”NetHttpBinding”>

         <reliableSession />

         <compositeDuplex />

         <oneWay />

         <binaryMessageEncoding />

         <httpTransport />


I was able to call the service successfully, but then client  was timed-out on response. It took me some time to debug until I recognized that the settings include    <oneWay />

Obviously it should be removed, if i am using a synchronous call.

So the minimum custom binding settings is
<binding name=”BinaryHttpBinding”>

          <binaryMessageEncoding />

         <httpTransport />


If you have big objects to transfer, you need to increase size limits similar to the following
       <binding name=”BinaryHttpBinding”><!–For Remoting–>
                   <binaryMessageEncoding >
                       <readerQuotas   maxStringContentLength=”43647″ />                    </binaryMessageEncoding>
                   <httpTransport maxReceivedMessageSize=”83647″ />                 </binding>

Discussion that helped