We’ve heard a lot of feedback since we first discussed our plans to create v1.5 of Data Services (http://blogs.msdn.com/astoriateam/archive/2009/03/01/announcing-ado-net-data-services-v1-5-ctp1.aspx). Since that time we’ve been busy improving the quality of the product, adding features and solidifying our release plans. The remainder of this post discusses our target release plan for the next version of Data Services and when the final bits will be available.
One area we heard consistent feedback on was the desire to limit the number of Data Service releases where possible. To address this need we have decided to change the ship vehicle for the release to be an in-place update of the data services binaries that shipped with the .NET Framework 3.5 SP1 (instead of a SxS release as was the case for the v1.5 CTP1 release). The release will ship as a redistributable update to the .NET Framework 3.5 SP1, which will include enhanced data services runtime assemblies and an updated datasvcutil.exe command line tool. As you’d expect, since the release is shipping as an update to the .NET Framework 3.5 SP1, all the binaries shipped with the release will be named as they were in the .NET Framework 3.5 SP1 release (i.e. System.Data.Services.*.dll). In addition to shipping an update to the .NET Framework 3.5 SP1, we’ll release a new Silverlight 3-compatible client library and the .NET-related client and server features from the .NET 3.5 SP1 update release will be directly included in the subsequent .NET Framework 4.0 release.
We will also be changing the release name to better convey that it is an in-place update to the .NET Framework 3.5 SP1. We’ll be dropping “v1.5” from the name and simply calling it the Data Services Update for the .NET Framework 3.5 SP1.
We aren’t yet ready to talk about a specific release date (we’re getting close :) ), but we are focused on this calendar year as our target window to release the update to the .NET Framework 3.5 SP1. After that, as mentioned above, the feature set will be directly included in the subsequent .NET Framework 4 release.
The feature set for the release will include the features we have already discussed on the data services blog (http://blogs.msdn.com/astoriateam/archive/2009/03/01/announcing-ado-net-data-services-v1-5-ctp1.aspx & http://blogs.msdn.com/astoriateam/archive/2009/08/31/ado-net-data-services-v1-5-ctp2-now-available-for-download.aspx )
Data Services, Lead Program Manager
thanks for this information. It's great to here that the update release will be included in .NET 4.0.
Have you also any information if the updated Client Library will also be included in the Silverlight 4.0 SDK?
@Thomas yes, we will include the feature set in the data service client library in the SL4 SDK as well. In fact an early look at that is available in the SL 4 SDK Beta release.
@Mike: Thanks for that information. Yes, I've already looked at the SL 4 SDK Beta release. But I came across the following error in my generated code
Generic Type System.Data.Services.Client.DataServiceCollection requires 1 type argument
Removed System.Data.Services.Client.dll from the references and added the Microsoft.Data.Services.Client.dll from the Bin-Folder of ADO.NET Data Services CTP 2 solved the problem.
So it seems that the System.Data.Services.Client.dll included in the SL 4 Beta Release is older that the Microsoft.Data.Services.Client.dll you provide with CTP2 download.
Looking forward when your Code from Microsoft.Data.Services.Client.dll goes into System.Data.Services.Client.dll for the final SL4 release.
Does this mean I won't have to jump through hoops to get VS to create observable client code?
@Josh Good question Josh. When you are creating an app targetting .NET Fx 4 or SL 4 then you will NOT need any additionals settings to get observable client side code gen. That said, if you are targetting an existing platform like .NET Fx 3.5 SP1 or SL3, then one additional setting will be required. This is done for backcompat reasons as we can't change a basic assumption like this for existing platforms as some folks rely on the non observable behavior in those cases.
@Thomas I believe the workaround for the issue you're hitting is explained in Shayne's recent blog entry, seen here: http://blogs.msdn.com/astoriateam/archive/2009/12/01/using-the-silverlight-4-0-wcf-data-services-client-library.aspx
@Matt: Yes, that's it. Thanks.