[Announcement] OData core libraries now support OData v4

Hi all,

We are tremendously excited to announce that we have released version 6.0.0 of the OData core libraries to NuGet on Jan 27th. This release is particularly noteworthy as it is the first production-ready release
with support for OData v4, the newest version of the OData protocol. We had two primary goals for this release:

  1. Feature parity. The new stack supports everything that was supported before, but all payloads and other functionality are now compliant with the v4 protocol.
  2. Selected new features. This release adds support for enum types, singletons and containment.

We have achieved both of these goals and are now well positioned to continue adding support for v4 features. 

Stack Prioritization & Strategy Adjustment

As you are probably aware, our team aligns with many teams inside and outside of Microsoft who are building OData services. This includes teams across every major division at Microsoft. Based on these engagements, we believe that Web API provides the right platform for OData services going forward and as such will be investing primarily in that platform for OData server stacks. We will of course continue to put significant resources into the OData core libraries and client, but we do plan to reduce investment in WCF Data Services as a stack for creating OData services. To mitigate the inconvenience this may cause, we are working on cleaning up the code and making it compatible with OData v4, and will then release that stack as open source. We do not plan to put any significant investment into adding v4-specific features to the WCF DS stack. Web API is actively working on adding support for OData v4 and nightly builds with OData v4 support will be available in February, with a public CTP to follow in March.

You might notice we have also made some branding changes to our client to align it more with the protocol. The client is and always has been an OData client (and not a WCF Data Services client), but now the name reflects the code more accurately. Also, we have adjusted our code generation strategy to use T4 rather than CodeDom. This means that if you want to have a customized code gen experience for your OData service, you can start from our T4 template and make whatever tweaks you wish.

Call to Action

If your team has an existing OData service or is considering adding an OData service, now is an excellent time to engage with us. In addition to building OData stacks, part of our charter is to help Microsoft align behind the OData protocol. If you need input on whether OData can do what your service needs to do, or input on what version of OData you should implement, please feel free to reach out to us at odatafeedback@microsoft.com.

Release Notes

The full release notes are as follows:

This release includes the core .NET libraries described below for implementing OData clients and services that comply with the Committee Specification 02 of the OASIS OData V4 Specification (http://docs.oasis-open.org/odata/odata/v4.0/cs02/part1-protocol/odata-v4.0-cs02-part1-protocol.doc). The libraries support the OData V4 JSON (http://docs.oasis-open.org/odata/odata-json-format/v4.0/cs02/odata-json-format-v4.0-cs02.doc) format; the Atom format is not supported in this release.

What is in the release?

  • Feature parity: This release supports the same set of features that were supported in version 5.6.0 of the OData core libraries. This release supports OData v4 only and is not backwards compatible with OData versions 1-3.
  • Enum support: The core libraries now have support for serializing and deserializing enum values in JSON payloads. The URI parser is able to parse enum values and operations including ‘has’.
  • Singleton support: The core libraries now have support for serializing and deserializing singleton values in JSON payloads. The URI parser is now able to parse singletons in paths.
  • Containment support : The core libraries now have support for serializing and deserializing contained values in JSON payloads. The URI parser is now able to parse contained paths.
  • Function support: The URI parser is now able to parse functions and function parameters in URLs.
  • OData v4 compatibility: The JSON format, $metadata format and URI parser have all been updated to support OData v4.

Known Limitations

  • This release of the OData core libraries targets functional equivalence with the 5.6.0 release as well as support for a few new features. This means that there are many new OData v4 features that are not supported yet in the core libraries.
  • Although the OData core libraries are capable of serializing the OData v4 Atom format, this functionality is not officially supported since the Atom specification has not yet made it to the CS02 stage.

Again, please feel free to reach out if you have any questions.


The OData Team

Comments (7)

  1. Adam says:

    As our business tier is written in WCF DS, I feel that we have been thrown under the bus on this decision.  We have invested so much effort in working around the weaknesses of  WCF DS  (prop change tracking, performance, containment, hackish T4 support for client proxies, terrible EF6 alpha quality provider, etc) and have been happily awaiting your new v4 release only to find out at this stage that you are abandoning it.  Switching to Web API at this point seems like we pay the price for every decision you make.  We are a Gold MS Partner.

  2. CNRice says:

    I would like to discuss this decision with the team.  How would you prefer I reach out to the OData team?  We have an ERP package that is a mix of Web API and WCF Data Service.   We use WCF Data Service just for the query part and Web API for any updates to data.  We also use EF and would like to upgrade to EF 6 but WCF Data Service isn't ready for that.  (I posted about that on the alpha EF6 provider).

    Ideally I would like to know to replicate the WCF Data Service EF provider in Web API.  I understand for OData to work in Web API we would need to expose IQueryable of our entitles.  But I really don't want to create a method for every single entity that I have in my data model.

  3. Vaccano says:

    First, throwing in the depreciation of the main product of the blog as a side note under an OData V4 post is poor communication.

    Second, this his harsh news to all those who have been following WCF DS.  To offer no real reasons beyond your belief "that Web API provides the right platform for OData services going forward" is weak.

    At least give all your supporters some real reasons why you have stopped development on WCF Data Services.

  4. freedompurveyor says:

    It would be nice to have a separate post explaining the decision to abandon WCF DS. It's a slap in the face to have it stuck in as a side note under "strategy adjustment." It's like you took a big ol' middle finger aimed at everyone who has dedicated countless hours to making a flawed product work (with the promise that you are working hard to make it better) and then hid it in a bowl of ice cream for us to find. Except, after you find the middle finger, the ice cream turns to dust.

    Thank you for your consideration.

  5. Ben says:

    I agree with the other comments about this announcement exhibiting poor communication.  This gives the impression that this is a relatively minor decision, which it is not.  Web API is not a simple drop-in replacement for WCF Data Services either in its implementation or its overall capabilities.  

    Companies like ours who are now a year and half into development using WCF Data services now have some difficult and critical decisions to make.  Especially considering that all the information you've given out in recent months regarding the coming OData 4 changes made no mention that they would only be for Web API.  Clearly this decision has been made for a while since the article references things coming in February and March even though this post was not made until March 21st.  Also no timeline was given on releasing the WCF Data Services stack as open source, which at this point may be our only realistic hope of avoiding some significant re-writing of some of our infrastructural components.

    This decision is just another example of an increasing and disturbing trend with Microsoft.  Everything we used to look to Microsoft for as developers – robust offerings, thorough documentation, strong technical support  and a stable platform – seems to increasingly be disappearing.  More and more my team finds ourselves asking why we are developing in the Microsoft stack at all when they seem so intent on forgetting developers (especially for enterprise-type solutions) in order to become a consumer products company.  It's difficult to know when starting a new project what technologies we should use when the sand is so frequently shifting under our feet in major areas like this and things that were very recently "the right way to do it" are seemingly quickly and casually dropped by the wayside.

    Things have changed a lot when you start feeling that you would get better communication, support and long-term stability from open-source solutions than from Microsoft.

  6. Anu says:

    Is it possible to develop WCF data Service supporting Odata V4

  7. Jim Deng says:

    When will WCF data Service be available in open source and when will it support Odata V4?