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.
"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
Post a Comment