The Cause and Solution for the "System.Runtime.Serialization.InvalidDataContractException: Type 'System.Threading.Tasks.Task`1[YourTypeHere]' cannot be serialized." Exception

The other day I worked on some new code that ran fine locally, but when deployed to one of our internal web servers threw the following exception:

"System.Runtime.Serialization.InvalidDataContractException: Type 'System.Threading.Tasks.Task`1[NameOfTheOffendingType]' cannot be serialized."

This had me scratching my head -- after all, to use that old developer's saying, "it worked fine on my machine". Not only that, but the exception was occurring when I was calling a method that didn't use the type mentioned in the exception (according to the stack trace it looks like the exception was happening during one of the many calls made under the hood during the use of a proxy class method). But once I found the cause of the problem, it made total sense. In this case, I had added a new WCF service reference to the project, and the proxy class that was generated for it was including some new task-based asynchronous operations that are supported in .NET 4.5. However, the web server in question was running .NET 4.0, which doesn't support these new operations.

Correcting the problem was easy. All I had to do was re-add the service reference, but this time click on the Advanced button in the Add Service Reference wizard and select a different option for asynchronous operations (see screenshot below). You have the option of not including the asynchronous operations by unchecking the "Allow generation of asynchronous operations" checkbox, or selecting one of two asynchronous operation options: "Generate task-based operations" (which was the cause of the problem in this situation and selected by default) and "Generate asynchronous operations" (yes it's really worded like that).


After resolving this issue, the question I had was "Why would this be the default option if the application itself isn't running .NET 4.5?" Well, I verified that the project was set to use 4.0, and also that, if you add a service reference to project that is not a 4.5 project, the asynchronous option is not enabled by default. Then remembered that I had created the actual proxy class in a different project due to our company policy of not having any direct service references but rather a separate assembly of proxies (don't ask) and that project was indeed set to use 4.5. Lesson learned.

Comments

Anonymous said…
THANK YOU!!!
Alan said…
You are very welcome. :)
Alex Solomon A said…
I have the same issue today and this article helps me to solve that. Thanks a lot
Alan said…
Glad to help. :)
Anonymous said…
Thank you!
Porschiey said…
Spent 2 hours trying to figure this out. You sir, are awesome. Thank you.
Anonymous said…
danke
Anonymous said…
Thanks! You're a lifesaver!
Anonymous said…
Thanks! :) Problem solved.
Unknown said…
Thanks! I'm using the Microsoft.Bcl.Async package with .Net 4. I think I'll recreate the proxy with begin & end methods and use Task.FromAsync() to still benefit from the async I/O.
Alan said…
Glad I could help. This was definitely a head-scratcher when I ran into the problem myself.
Devendra Thakur said…
This comment has been removed by the author.
Devendra Thakur said…
we had same issue and this article helps us. Thanks !!!!
Hariharan KV said…
Thanks Alan, helped me too..!! :)
Anonymous said…
Thank you
JD said…
Thanks a ton....ur a genius.
Anonymous said…
Greate! Thank you
Anonymous said…
Thank you. This solved our problem as well.
Anonymous said…
You saved my day ! Thanks !
_scuzzy said…
Legend! I just spent a whole day with this issue!
Mike Lewis said…
Excellent summary. Thank you for keeping this page online with the resolution.
Unknown said…
Thanks Alan , it helped me too.

Popular posts from this blog

How To Mock Out Child Components In Unit Tests of Angular 2 Code

A Generic Method Using HttpClient to Make a Synchronous Get Request