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.
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.
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.
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.
Where's the link to the installer? Do we even need the installer?
Do we need new tools for Visual Studio?
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?
Can you provide a link about Instance annotations about how to use them ?
@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 firstname.lastname@example.org.
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.
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.
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.
Does this version will have full support for the enum data type?
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);
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))
if (primitiveClrType != typeof(double))
throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDouble(primitiveTypeReference.ODataFullName()));
if (value is bool)
if (primitiveClrType != typeof(bool))
throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertBoolean(primitiveTypeReference.ODataFullName()));
if (value is DateTime)
if (primitiveClrType != typeof(DateTime))
throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDateTime(primitiveTypeReference.ODataFullName()));
if ((value is DateTimeOffset) && (primitiveClrType != typeof(DateTimeOffset)))
throw new ODataException(Microsoft.Data.OData.Strings.ODataJsonReaderUtils_CannotConvertDateTimeOffset(primitiveTypeReference.ODataFullName()));
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!
@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 (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.
@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).
In batch updates, in batch updates when Int64 are encoded as "1234L".
It does work when they are encoded as "1234"
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?