RTM is here!
ADO.NET Data Services (aka “Project Astoria”) has Released! Today marks the official RTM of Visual Studio 2008 SP1 and the .NET Framework 3.5 SP1, and we are thrilled to announce the official RTM of the ADO.NET Entity Framework and ADO.NET Data Services.
You can find more information and download SP1 at http://msdn.microsoft.com/data .
The remainder of this post will cover the changes and additions to the ADO.NET Data Services Framework since the Beta. This post will just give a brief summary of each and we’ll follow up with more targeted posts overtime to get a bit deeper into the details.
Changes \ Enhancements:
Tweaks to the ATOM payload: We've made a few tweaks to the payload format based on feedback from the ATOM community and to enable us to land on a simpler overall set of semantics for CRUD operations across resources and links between resources. One of the most significant improvements is that links/associations are now directly addressable so it’s clear when you are working with an link\association vs. working with a resource\entity. Using the Northwind database schema as an example, to address the set of links between a Customer and their Orders, the following URI is available: http://myserver/myservice/Customers(‘ALFKI’)/$links/Orders. This new $links segment allows associations to be addressed and manipulated directly. We’ll follow up with additional examples and whitepapers showing the details of this syntax in future posts.
A handful of bug fixes J.
Tweaks to our optimistic concurrency support: We added support for the ‘*’ character to be used with conditional HTTP requests. We also changed to use weak Etags instead of strong Etag values to better align with the HTTP spec and its current set of ammendums.
Tweaks to the .NET client library: The response object from the SaveChanges(…) method has changed to make it easier to get at all aspects (headers, etc) of each section of the data service response. The most significant difference is the HasErrors properties from the *Response classes are removed. Instead, if one or more errors occur during the processing of a call to SaveChanges(…), the method will throw an exception. The exception contains a property to access the full response to determine which operations succeeded and which failed (assuming SaveChangesOptions.Batch was not used which provides “all or nothing” semantics).
Additional configuration of system limits: A number of system limits are now publically exposed via the IDataServiceConfiguration class enabling a data service author more control over the requests their service is willing to accept and process
Additional plug-in points in the processing pipeline: Just after URI syntactic analysis is complete, we have added a call out in the processing pipeline called OnStartProcessingRequest. This call out enables custom service code to run at a very early point in the request processing pipeline.
“Add Service Reference” support for client proxy generation: The command line tool to generate client side types for a data service (datasvcutil.exe) can still be found in the \Windows\Microsoft.Net\Framework\V3.5 directory; however, we are pleased to announce the “Add Service Reference” feature in Visual Studio now supports accepting ADO.NET Data Service URIs.
Service versioning support: Data services now directly support a lightweight versioning scheme enabled via HTTP headers. The scheme has been designed with the goal of enabling existing clients to work with new service versions (and vice versa) when safely possible. The goal was taken as it seems for internet facing data services one needs to assume clients and services will rev at different speeds.
Control error messages: Data service authors can now easily control all error messages and associated status codes returned to a client as a result of an error while processing a data service request. The HandleException method on the DataService class is now called for any exception that occurs while processing a request. A data service author can then map any downstream exception to sections of the error message structure used by data services.
We want to work on a round of blog posts to address a few of the common questions folks have when using data services. We’ve got a number in mind already, but if you have a question/comment that would make a good blog post let us know. We likely won’t be able to answer each with a full blog post, but we’ll try to address the common ones.
Program Manager, ADO.NET Data Services