WCF Data Services 5.3.0 RTW

Today we are releasing an updated version of the WCF Data Services NuGet packages and tools installer. As mentioned in the prerelease blog post, this version of WCF DS has three notable new features as well as over 20 bug fixes.

What is in the release:

Instance annotations on feeds and entries (JSON only)

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. WCF Data Services 5.3.0 supports instance annotations in JSON payloads. Support for instance annotations in Atom payloads is forthcoming.

Action Binding Parameter Overloads

The OData specification allows actions with the same name to be bound to multiple different types. WCF Data Services 5.3 enables actions for different types to have the same name (for instance, both a Folder and a File may have a Rename action). This new support includes both serialization of actions with the same name as well as resolution of an action’s binding parameter using the new IDataServiceActionResolver interface.

Modification of the Request URL

For scenarios where it is desirable to modify request URLs before the request is processed, WCF Data Services 5.3 adds support for modifying the request URL in the OnStartProcessingRequest method. Service authors can modify both the request URL as well as URLs for the various parts of a batch request.

This release also contains the following noteworthy bug fixes:

  • Fixes an issue where code gen produces invalid code in VB
  • Fixes an issue where code gen fails when the Precision facet is set on spatial and time properties
  • Fixes an issue where code gen was incorrectly generating the INotifyPropertyChanged code for subtypes in different namespaces
  • Fixes an issue where odata.type was not written consistently in fullmetadata mode for JSON
  • Fixes an issue where a valid form of Edm.DateTime could not be parsed
  • Fixes an issue where the WCF DS client would not send type names for open properties on insert/update
  • Fixes an issue where the client Execute() method would fail for a particular payload with DataServiceVersion=1.0
  • Fixes an issue where type information was omitted in JSON fullmetadata payloads
  • Fixes an issue where open property type information was omitted in JSON update/insert requests
  • Fixes an issue where it was not possible to navigate relationships on entities with multi-part keys
Comments (16)

  1. Cecil says:

    Where's the link to the installer? Do we even need the installer?

  2. Leon Meijer says:

    Do we need new tools for Visual Studio?

  3. Can you shed some light on the future roadmap of WCF Data Services? It seems rather strange that the Web API team is currently investing heavily on supporting what essentially seems to be the same OData functionality available in WCF Data Services. Will the two products converge in the future, or will they continue as separate products with overlapping functionality?

  4. DotNetWise says:

    Can you provide a link about Instance annotations about how to use them ?

  5. @Cecil – installer finally made it up to the download center; we've updated the blog post. Sorry for the delay, the sign off process for releasing MSIs usually happens faster.

    @Leon – you only need new tools if you were experiencing one of the bugs we fixed. Post is updated with the link to the installer.

    @Michael – that's a good question, and probably more suited to a blog post than a comment response, but here's a short answer: Web API's OData stack is built on top of ODataLib, which is the core of WCF Data Services. We currently view these as two different high-level stacks that target different scenarios and API flavors. It could be that the products will converge more in the future, but for now their roadmaps will remain separate. If you're currently using WCF Data Services, you don't need to switch to Web API unless you're experiencing problems you believe Web API will solve for you. To the best of my knowledge it's possible to host WCF Data Services endpoints and Web API endpoints side-by-side in an ASP.NET application. Use what fits. Most importantly, don't worry that this will turn into a L2S vs. EF issue. Since both stacks are working on top of a common core, the differences are mostly isolated to high-level APIs and request pipeline.

    @DotNetWise – we'll publish more about instance annotations in the near-ish future; 5.4.0 will have a lot more support there and so there will be more of a need for documenting them. For now, I can comment that we view instance annotations as part of the extensibility story of OData; marking up your response with instance annotations allows you to provide data apart from that specified in the model. If you need more detail in the short term, please feel free to e-mail me directly at mastaffo@microsoft.com.

  6. Note on the installer link – you may need to force your browser window to refresh; that page used to host the 5.2.0 tools installer.

  7. Brendan says:

    Note that the problem discussed in on this page: aspnetwebstack.codeplex.com/…/721 remains broken in this version. I had to roll back to Version 5.2.0-rc1.

  8. Using NuGet, I installed version 5.3, but now my app fails with a message that the manifest definition des not match the assembly reference.  When I try to add reference, the 5.3 versions of Data.Service do not appear in the list. How do I resolve this.

  9. Raul Rodriguez says:

    Does this version will have full support for the enum data type?

  10. DotNetWise says:

    The following method from the class `ODataJsonLightReaderUtils` does not implement correctly OData sepcifications!!!


    For Int64 it should handle "1234L" as well as "1234". Convert.ChangeType fails gracefully!


    internal static object ConvertValue(object value, IEdmPrimitiveTypeReference primitiveTypeReference, ODataMessageReaderSettings messageReaderSettings, ODataVersion version, bool validateNullValue)


               if (value == null)


                   ReaderValidationUtils.ValidateNullValue(EdmCoreModel.Instance, primitiveTypeReference, messageReaderSettings, validateNullValue, version);

                   return null;




                   Type primitiveClrType = EdmLibraryExtensions.GetPrimitiveClrType(primitiveTypeReference.PrimitiveDefinition(), false);

                   string stringValue = value as string;

                   if (stringValue != null)


                       return ConvertStringValue(stringValue, primitiveClrType);


                   if (value is int)


                       return ConvertInt32Value((int) value, primitiveClrType, primitiveTypeReference);


                   if (value is double)


                       double num = (double) value;

                       if (primitiveClrType == typeof(float))


                           return Convert.ToSingle(num);


                       if (primitiveClrType != typeof(double))


                           throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDouble(primitiveTypeReference.ODataFullName()));


                       return value;


                   if (value is bool)


                       if (primitiveClrType != typeof(bool))


                           throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertBoolean(primitiveTypeReference.ODataFullName()));


                       return value;


                   if (value is DateTime)


                       if (primitiveClrType != typeof(DateTime))


                           throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDateTime(primitiveTypeReference.ODataFullName()));


                       return value;


                   if ((value is DateTimeOffset) && (primitiveClrType != typeof(DateTimeOffset)))


                       throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDateTimeOffset(primitiveTypeReference.ODataFullName()));




  11. DotNetWise says:

    Why there in the oData crazy limited world nobody thought of supporting bitwise operators?

    & | ^ ~

    They could simply be translated by using the current supported operators: and or not – there is no match for xor, but that can be hardly rewritten with the current (and, not, or) math.stackexchange.com/…/is-xor-a-combination-of-and-and-not-operators

    Strengely enough, they ARE supported in .NET Framework, in Entity Framework, in Linq-to-SQL in SQL Server and in MySQL. Presumably they are supported in Oracle as well.

    So, for example, if the backend is EntityFramework and that is supporting them, why doesn't WCF Data Services translate them as such?

    As for the OData protocol is already almost all in there.

    $filter=(Role and 32) eq 32 would really make sense to be translated as WHERE Role & 32 = 32 or even: WHERE Role AND 32 = 32

    So please Pablo Castro add them to WCF Data Services too! We are really missing them!

  12. @Brendan – I apologize for the trouble you're having, but if this is still broken, it's an issue in the Web API stack and I'm sure they're working on it. See this gist (gist.github.com/…/5135588) for a sample using just EdmLib and ODataLib.

    @RentAPlace – Do you have multiple projects in your solution? This isn't something we've seen happen before, but it sounds like a NuGet issue.

    @Raul – No, OData v3 as a protocol does not support enums. OData v4 will, and WCF DS should have a stack that supports v4 sometime later this year. (Although most likely it will take us a bit longer to actually get support for enums.) On the plus side, it will be appropriately integrated – you'll be able to do things like http://mysvc/FileRights?$filter=FileExtension eq txt and Rights has Write. (Note the 'has' operator for working with flagged enums.)

    @DotNetWise – Do you have an actual scenario that's failing or are you just looking for "Int64" in that method? Integers that large have to be serialized as strings because JavaScript loses precision past 15 digits. So in this case there would be a string value, an annotation that indicates that it's a long value, and we'd hit the ConvertStringValue part of the method below.

    @DotNetWise (2nd comment) – Bitwise operators aren't supported today because enums don't have first class support. Even when we get first class support, we won't do straight bitwise operators, instead we will use the existing operators and add a 'has' operator for the (FlagValue & Flag) = Flag scenario, which is only tolerable by programmers (that is, the syntax would be 'FlagValue has Flag'). We'd love to hear feedback on this if it's the wrong approach.

  13. @DotNetWise – actually, you may be running into an issue where an 'L' suffix is allowed in the URI literal form but not in the payload (see section 2.2.2 of MS-ODATA, msdn.microsoft.com/…/dd541295.aspx).

  14. Int64 encoding fails says:

    In batch updates, in batch updates when Int64 are encoded as "1234L".

    It does work when they are encoded as "1234"

  15. drdamour says:

    any plans to get the System.Data.Spatial.DbGeography supported by EF working with the System.Spatial type supported by WCF?  Is there any guidance on how to do a workaround for this?

  16. Rubens Cordeiro says:

    how can I modify the url method OnStartProcessingRequest?

    I'm trying, and I get the message. "The query string of the request URI can not be modified in the OnStartProcessingRequest method."

    Someone can help me, thanks