WCF Data Services 5.3.0 RTW

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 mastaffo@microsoft.com.

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!!!

msdn.microsoft.com/.../dd541461.aspx

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;

           }

           try

           {

               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()));

               }

           }

  ```

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 - 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.

@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?