WCF Data Services 5.4.0 Prerelease
Recently we uploaded an RC for our upcoming 5.4.0 release. This release will be NuGet packages only.
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
What to expect over the next six months:
We will blog about this in more detail soon, but we have multiple releases planned that have some level of overlap. We should be publishing a 5.5.0 alpha soon (with additional URI parser functionality for Web API’s OData stack) and in a couple of months you should see a very early alpha of 6.0.0. We’re not ready to say much about 6.0.0 yet other than the fact that it will support OData v4 and will probably have some breaking changes, so we want to get it out there as soon as possible because…
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 would encourage you strongly to start pulling down these early bits, testing with your existing services, and telling us where things break, where we’ve gone too far, and where we haven’t gone far enough.
Comments
Anonymous
March 26, 2013
Sometimes when we innovate too quickly and have too many options available, it confuses our clients....Anonymous
March 26, 2013
The comment has been removedAnonymous
March 27, 2013
Why are both the WCF and WebApi teams both working on OData? Wouldn't it make sense for both teams to consolidate and work toward one implementation going forward. I just am confused about which implementation to use - fearing that in the future, only one will be the winner.Anonymous
March 27, 2013
I wonder if it fixes this issue? : social.msdn.microsoft.com/.../ae0033de-d97b-4b92-9c6e-98abe5d89321Anonymous
April 01, 2013
@JimBobPop - thanks for the feedback; I can say that we're definitely headed in the portable libraries direction which will make feature parity across platforms much easier. Also, we do eventually intend for the T4 template to become the primary code-gen experience; prioritization is the only obstacle at this point. @Todd - you probably won't be surprised if I tell you that's not the first time we've heard that feedback, but I can assure you that we don't think this is a repeat of LINQ2SQL vs. EF. The biggest difference is that L2S and EF were playing in the exact same space without sharing a common foundation. That is not the case with WCF DS and Web API - we are both working off a shared foundation (ODataLib). Currently the products meet two very different needs and have very different flavors of API, so there are absolutely no plans to sunset WCF DS. Our typical guidance is that if you have a LINQ provider and don't need advanced business logic in that particular layer, WCF DS is probably an ideal fit. If you don't have a LINQ provider or have exotic business logic in that layer, Web API is probably a better fit. @Ross - no, I don't think it fixes that issue. Our server is pretty sensitive to headers and such so it seems like the headers might be getting modified somewhere in the relay. Feel free to e-mail me if you don't get a response on the forum.