Share via

WCF Data Services 5.5.0 Release

  • Article

WCF Data Services 5.5.0 has officially been released! The 5.5.0 release will be another NuGet-only release as we did not make any updates to the Visual Studio tooling.

The last tooling update was version 5.3.0. Services created using this version of tooling should update the runtime binaries to 5.5.0 with NuGet.

What is in the release:

This release has two primary features: 1) significant enhancements to the URI parser and 2) public data source providers. In addition to the primary features, there are two secondary enhancements and over 40 bug fixes included with this release.

URI Parser

In the 5.2.0 release ODataLib provided a way to parse $filter and $orderby expressions into a metadata-bound abstract syntax tree (AST). In the 5.5.0 release we have updated the URI parser with support for most OData URIs. The newly introduced support for parsing $select and $expand is particularly notable. With the 5.5.0 release the URI Parser is mostly done. Future releases will focus on higher-order functions to further improve the developer experience. 

Public Data Source Providers

In this release we have made the Entity Framework and Reflection data source providers public. This gives more control to service writers. There is more work planned in the future but the work we’ve completed allows some advanced scenarios which were not possible earlier. For example, a service writer can now make use of the Entity Framework query-caching feature by intercepting the request and parameterizing the LINQ query before handing it off to Entity Framework. (Note that parameterizing a LINQ query is not the same as parameterizing a SQL query; EF always does the latter and therefore there is no security implications to failing to parameterize a LINQ to Entities query, the only impact is performance related.)

While the potential unlocked with this release is limited, this is the first move in a direction which will unlock many previously unachievable scenarios with the built in providers.

Performance Improvements

We constantly strive to improve performance and reliability with every release. In this release, we have increased performance by double digit percentages for service authors that want to respond with JSON but are not able to (or don't want to) provide a data model to ODataLib.

Improved Developer Experience

In this release we have caught up with some missing IntelliSense guidance and we are uploading symbols and source to SymbolSource.org. We will upload symbols for many of our past releases as well.

Bug Fixes

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

  • Fixes an issue where the reflection provider would not work properly if the generic parameter provided to DataService<T> was an interface
  • Fixes an issue where some system headers were not being set when a client called BuildingRequest
  • Fixes an issue where setting InstanceContextMode to Single on DataService would result in cache result being returned for subsequent requests
  • Fixes an issue where ODataLib would sometimes allow null to be written whether or not the expected type was nullable
  • Fixes a regression in 5.4 where ODataLib started writing unnecessary type information in certain instances
  • Fixes an issue where the WCF DS client would sometimes not dispose the response if the response had no content
  • Improves a number of errors and error messages

Comments

  • Anonymous
    May 30, 2013
    Can you give an example of how to hook in to the Entity Framework data source provider?

  • Anonymous
    May 30, 2013
    Seconding MikeH's comment. Please provide an example. This leads on to more general feedback. Whilst it is great that you're regularly releasing updates, can you please ensure all new features are documented, as they aren't much use if I don't know how to use them (and if they already are documented, these blog announcements would be a great place to link to updated documentation). Looking forward to seeing what is possible with the new public providers. Cheers.

  • Anonymous
    May 31, 2013
    Did you guys ever officially include the OData T4 for C# functionality described here: blogs.msdn.com/.../announcing-odata-t4-for-c-preview-1.aspx What I'm trying to do is to auto-generate Knockout.js bindable javascript / coffeescript classes using oData MetaData and T4 templates.  Is this possible?

  • Anonymous
    June 01, 2013
    Great stuff. Any chance the Entity Framework would ever be able to support properties that are only part of the c# classes but not of the database itself? e.g. any sort of computed properties / complex types / classes and properties that would automatically fallback to the reflection provider? Also is there any way of adding an "AfterSave" interceptor? This way you could trigger certain c# actions such as sending an email after a save operation was done on a certain resource.

  • Anonymous
    June 03, 2013
    @DotNetWise Would appreciate such a feature as well!

  • Anonymous
    June 05, 2013
    I just updated my WCF DS Toolkit fork with 5.5.0, if anyone is interested. Get it at: github.com/oising/WCFDS-Toolkit  -- there's a link to the NuGet package too.

  • Anonymous
    June 09, 2013
    @Josh Good question! I'm also using the prerelease version of the T4 template looking further to a released one

  • Anonymous
    June 10, 2013
    The comment has been removed

  • Anonymous
    June 11, 2013
    Hello I have the following trouble (WCF Data Services 5.5.0):    •   I have one project “A” containing complex type classes.    •   I have one project “B” containing entity type classes.    •   I have one project “C” where I have a custom WCF Data Service implementation based on the class types of “B” and they references complex types in “A”. I don’t know why if I directly create a resource types with one “NamedNamespace” the metadata refers the resource types with the CLR type (InstanceType) namespace. In consequence when I like have all the resource type under this “NamedNamespace” I have 3 schema with namespaces: “A” because the complex type classes, “B” because the entity type classes and “NamedNamespace” I am not sure exactly why: could be because the resource type namespaces I built or because the namespace of the assembly containing the custom WCF Data Service implementation (are the same this time). The worst is when I add service reference I have one error because the code namespaces generated are not recognized in code! Regards

  • Anonymous
    June 12, 2013
    Hello Again: I forgot to include other questions with my last post. 1 - I have received errors browsing the custom data service when I don’t set the resources like ReadOnly, I don’t know why, but I think me missing something.   2 – I had to refuse the use the public reflection provider because it do not allow me skip the SetReadOnly step to be able add more logic to the resource definitions. I commented about my scenary on WCF Data Service 5.5.0 prerelease, I cited here:   "Tue, May 21 2013 3:51 PM Thanks you guys, you are doing amazing work here with WCF Data Services, I really appreciate you make  public the built-in providers. I had been making pitfalls loading them through reflection. I have been moving towards some scenaries where a different perspective could be nice. For example I’ve been working around to generate a custom WCF Data Service Provider from one Entity Data Model (it is extended with custom annotations to guide layer code generation). I’ve read your source code to follow your logic, but I discovered many logic that I cannot do myself because it requires access to internal members, for example the custom annotations. I use the EDM on design mode, that means you must create a EDM, annotate it with custom annotations on EF designer and I generate the source code to cover the application architecture logic, but you really don’t have the EDM on runtime.  It means I cannot use the built-in WCF Data Service EF provider, then I use your Reflection Provider.  Of course I dealt too with missing features like enum support. I don’t understand why, at least, you don't generate enum properties based on numeric enum type (byte, int). Is there any problem with this temporal solution? The reflection provider requires one defined type with properties and all steps you know it’s needed. Could the reflection provider do expose members to make fluent and interactive metadata generation? For example: GetResourceType(Type t), GetResourceProperty(PropertyInfo info), it can allow to me useyour baseline logic and insert my own information including but not limited to virtual properties and/or associations. I guess I cannot emit the virtual types because on these cases the InstanceType will not be the real type. Regards. PD: If you need I can write more details about my scenary." Regards

  • Anonymous
    June 13, 2013
    I switched to using the WebApi OData solution as this seemed to be where MS was putting in more effort, but now you guys have just done a new release. Can you help me decide which one I should be using?!

  • Anonymous
    June 14, 2013
    please!!!! renew documentation  for custom provider dev. please!!!! some words about ASYNC on SERVER SIDE.

  • Anonymous
    July 17, 2013
    Excellent Post. Also visit www.msnetframework.com

  • Anonymous
    August 26, 2013
    Hi, I've found an issue similar to the one reported here: stackoverflow.com/.../wcf-dataservice-metadata-typemismatchrelationshipconstraint What seems to be happening is that when a FK is based on more than one column, the WCF Data Services somehow forgets which column in one table links to the column in the other table, and if they have diferente datatypes, the reported error happens. I've posted a longer comment last weekend but it never showed up, so if you have both comment waiting to be published, choose one :)