Partilhar via


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

  • Anonymous
    February 18, 2013
    Where's the link to the installer? Do we even need the installer?

  • Anonymous
    February 19, 2013
    Do we need new tools for Visual Studio?

  • Anonymous
    February 19, 2013
    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?

  • Anonymous
    February 22, 2013
    Can you provide a link about Instance annotations about how to use them ?

  • Anonymous
    February 25, 2013
    The comment has been removed

  • Anonymous
    February 25, 2013
    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.

  • Anonymous
    March 01, 2013
    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.

  • Anonymous
    March 01, 2013
    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.

  • Anonymous
    March 02, 2013
    Does this version will have full support for the enum data type?

  • Anonymous
    March 07, 2013
    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()));
                }
            }
   ```
  
* **Anonymous**  
March 08, 2013  
The comment has been removed  
* **Anonymous**  
March 11, 2013  
@Brendan - I apologize for the trouble you&#39;re having, but if this is still broken, it&#39;s an issue in the Web API stack and I&#39;m sure they&#39;re working on it. See this gist (<a href="https://gist.github.com/markdstafford/5135588">gist.github.com/.../5135588</a>) for a sample using just EdmLib and ODataLib.
@RentAPlace - Do you have multiple projects in your solution? This isn&#39;t something we&#39;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&#39;ll be able to do things like http://mysvc/FileRights?$filter=FileExtension eq txt and Rights has Write. (Note the &#39;has&#39; operator for working with flagged enums.)
@DotNetWise - Do you have an actual scenario that&#39;s failing or are you just looking for &quot;Int64&quot; 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&#39;s a long value, and we&#39;d hit the ConvertStringValue part of the method below.
@DotNetWise (2nd comment) - Bitwise operators aren&#39;t supported today because enums don&#39;t have first class support. Even when we get first class support, we won&#39;t do straight bitwise operators, instead we will use the existing operators and add a &#39;has&#39; operator for the (FlagValue &amp; Flag) = Flag scenario, which is only tolerable by programmers (that is, the syntax would be &#39;FlagValue has Flag&#39;). We&#39;d love to hear feedback on this if it&#39;s the wrong approach.
  
* **Anonymous**  
March 11, 2013  
@DotNetWise - actually, you may be running into an issue where an &#39;L&#39; suffix is allowed in the URI literal form but not in the payload (see section 2.2.2 of MS-ODATA, <a href="http://msdn.microsoft.com/en-us/library/dd541295.aspx">msdn.microsoft.com/.../dd541295.aspx</a>).
  
* **Anonymous**  
March 14, 2013  
In batch updates, in batch updates when Int64 are encoded as &quot;1234L&quot;.
It does work when they are encoded as &quot;1234&quot;
  
* **Anonymous**  
March 21, 2013  
any plans to get the System.Data.Spatial.DbGeography supported by EF working with the System.Spatial type supported by WCF? &nbsp;Is there any guidance on how to do a workaround for this?
  
* **Anonymous**  
March 24, 2013  
how can I modify the url method OnStartProcessingRequest?
I&#39;m trying, and I get the message. &quot;The query string of the request URI can not be modified in the OnStartProcessingRequest method.&quot;
Someone can help me, thanks