WCF Data Services 5.4.0 Release

Today we are releasing version 5.4.0 of WCF Data Services. As mentioned in the prerelease post, this release will be NuGet packages only. That means that we are not releasing an updated executable to the download center. If you create a new WCF Data Service or add a reference to an OData service, you should follow the standard procedure for making sure your NuGet packages are up-to-date. (Note that this is standard usage of NuGet, but it may be new to some WCF Data Services developers.)


If you haven’t noticed, we’ve been releasing a lot more frequently than we used to. As we adopted this rapid cadence, our documentation has fallen somewhat behind and we recognize that makes it hard for you to try out the new features. We do intend to release some samples demonstrating how to use the features below but we need a few more days to pull those samples together and did not want to delay the release. Once we get some samples together we will update this blog post (or perhaps add another blog post if we need more commentary than a gist can convey).

What is in the release:

Client deserialization/serialization hooks

We have a number of investments planned in the “request pipeline” area. In 5.4.0 we have a very big set of hooks for reaching into and modifying data as it is being read from or written to the wire format. These hooks provide extensibility points that enable a number of different scenarios such as modifying wire types, property names, and more.

Instance annotations on atom payloads

As promised in the 5.3.0 release notes, we now support instance annotations on Atom payloads. Instance annotations are an extensibility feature in OData feeds that allow OData requests and responses to be marked up with annotations that target feeds, single entities (entries), properties, etc. We do still have some more work to do in this area, such as the ability to annotate properties.

Client consumption of instance annotations

Also in this release, we have added APIs to the client to enable the reading of instance annotations on the wire. These APIs make use of the new deserialization/serialization pipelines on the client (see above). This API surface includes the ability to indicate which instance annotations the client cares about via the Prefer header. This will streamline the responses from OData services that honor the odata.include-annotations preference.

Simplified transition between Atom and JSON formats

In this release we have bundled a few less-noticeable features that should simplify the transition between the Atom and (the new) JSON format. (See also the bug fixes below on type resolver fixes.)

Bug fixes

In addition to the features above, we have included fixes for the following notable bugs:

  • Fixes an issue where reading a collection of complex values would fail if the new JSON format was used and a type resolver was not provided
  • Fixes an issue where ODataLib was not escaping literal values in IDs and edit links
  • Fixes an issue where requesting the service document with application/json;odata=nometadata would fail
  • Fixes an issue where using the new JSON format without a type resolver would create issues with derived types
  • (Usability bug) Makes it easier to track the current item in ODataLib in many situations
  • Fixes an issue where the LINQ provider on the client would produce $filter instead of a key expression for derived types with composite keys
  • (Usability bug) Fixes an issue where the inability to set EntityState and ETag values forced people to detach and attach entities for some operations
  • Fixes an issue where some headers required a case-sensitive match on the WCF DS client
  • Fixes an issue where 304 responses were sending back more headers than appropriate per the HTTP spec
  • Fixes an issue where a request for the new JSON format could result in an error that used the Atom format
  • Fixes an issue where it was possible to write an annotation value that was invalid according to the term
  • Fixes an issue where PATCH requests for OData v1/v2 payloads would return a 500 error rather than 405

We want your feedback

We always appreciate your comments on the blog posts, forums, Twitterverse and e-mail (mastaffo@microsoft.com). We do take your feedback seriously and prioritize accordingly. We are still early in the planning stages for 5.5.0 and 6.0.0, so feedback now will help us shape those releases.

Comments (14)

  1. Michael says:

    Are future releases of WCF Data Services going to be NuGet only too with no corresponding installer?   Or was this situation just for this fast release?   Thanks

  2. Peter LaComb says:

    I had to double-check, but it's really good to see that Asp.net Web API ODATA (http://www.nuget.org/…/microsoft.aspnet.webapi.odata) Has been updated to be compatible!

  3. @Michael – we currently only plan to update the installer when we have fixes to code-gen or something that requires the installer to be updated. Otherwise we expect that all of our releases will be NuGet only. Is there a particular reason you ask? Something we might be missing?

    @Peter – agreed, but it's good to recognize that ODataLib will get updates on the WCF DS release schedule and Web API may or may not take advantage of those updates in the future. We do work really closely together to make this as seamless as possible, though!

  4. DotNetWise says:

    Is there a link with documentation about annotations?

    In 5.3.0 was missing, was it being written?

  5. DotNetWise says:


    Seems like it's ancient and long time updated.

    "Announcing the WCF Data Services June CTP" You have two months and there will be maybe another June CTP but of 2013 🙂

  6. DotNetWise says:

    I'm getting the following error when I'm trying to add WCFDS to an older project who was already using WCF Services (System.ServiceModel and System.ServiceModel.Web that is)

    Error 2 The type 'System.Data.Services.IUpdatable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Services, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

    However if I add it I'll get another error

    Error 2 The type 'System.Data.Services.DataService<T>' exists in both 'packagesMicrosoft.Data.Services.5.4.0libnet40Microsoft.Data.Services.dll' and 'c:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.0System.Data.Services.dll'

    So how to deal in this situation?

  7. Lane says:

    Error 1 The type 'System.Data.Services.IUpdatable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Services, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

    Error 2 The type 'System.Data.Services.Providers.IDataServiceUpdateProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Services, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

    But the NuGet package removes the references to the .NET Framework System.Data.Services.dll and System.Data.Services.Client.dll and is replaced with the Microsoft.Data.Services.dll and the Microsoft.Data.Services.Client.dll

    Soooo, if you try to add back the  System.Data.Services.dll and System.Data.Services.Client.dll you get the

    The type 'System.Data.Services.DataService<T>' exists in both Microsoft.Data.Services.dll and System.Data.Services.dll errors…

    There doesn't seem to be a way around this!

  8. DotNetWise says:

    I've found a way around it.

    I've put an alias to Microsoft.Data.Services assemblies named microsoft.

    In the new odata service I have defined the extern microsoft alias and used them as

    use microsoft::System.Data.Services;

  9. Leon Meijer says:

    Is there now a way to access the HTTP body and headers of the outgoing HTTP requests? I'm looking for a way to capture the full 'wire message', because I have a requirement to store them.

  10. João Vitor says:

    Guys, i am having some problem about DataService… can someone verify if that will be fixed in a future version of dataservice?

    Here is the link about the issue: stackoverflow.com/…/wcf-dataservice-and-entityframework-poco-proxy

    I really apreciate a look from the wcf team. thanks anyway.

  11. Best place for bug reports and other input? says:

    I've submitted a few bug reports on gotvoice, but haven't received any feedback.  Where is the best place to post input?

  12. Uffe says:

    The best place to receive support is the WCF DS forum. social.msdn.microsoft.com/…/adodotnetdataservices

  13. James says:

    When are we going to have OData function feature? And what is the story about service operation after that? Thanks

  14. Alan Godfried says:

    I am having issues which I think may be a bug.

    override void HandleException in WCF Data Service ceases to work when overriding SaveChanges in EF.


    EF 5.0

    WCF Data Services 5.4

    VS Studio Pro 2012

    To produce the issue:

    Within a WCF Data Service project, override the exception handler in the data service. Then override SaveChanges() in EF. Then, using a data service client, do a data update that produces an exception such as saving a record missing a required field.

    What happens:

    The overridden exception handler is not called when an exception occurs. A breakpoint set on the first line of the handler is not reached when an exception occurs.

    Should happen:

    The method:

       protected override void HandleException(HandleExceptionArgs args)

    should be called, but it isn't.

    Removing the SaveChanges() override resolves the issue and the HandleException override works properly!

Skip to main content