ADO.NET Data Services 1.5 and SharePoint 2010 allow developers to write applications against SharePoint Lists using the familiar Data Services Client programming model.

Setup

The SharePoint 2010 beta will become generally available in November.

In order to use Data Services with SharePoint 2010 Beta, ADO.NET Data Services 1.5 must be installed on your server, ideally *before* you install SharePoint 2010.

If however SharePoint 2010 is already on your box when you install Data Services, you will need an iisreset to make the Data Service Endpoint show-up.

And then to program against a Data Services enabled SharePoint box you need either:

• VS 2008 SP1 with the ADO.NET Data Services 1.5 installed (CTP 2 only – the RTM is incompatible with the SharePoint 2010 Beta)
  
  or
  
• VS 2010 (Beta 2 or higher)

Where is your Data Service Endpoint?

Assuming you’ve got everything setup and working the first thing you need to know is where your Data Service endpoint is installed.

If your SharePoint site is http://mflasko-dev/ (thanks Mike) then your Data Services endpoint will be http://mflasko-dev/_vti_bin/listdata.svc.

If you open one of these endpoints up in Internet Explorer you’ll see something like this:

As you can see this is a standard Data Services Atom feed, listing all the Lists on the SharePoint site.

Cool.

Once you know where your Data Service is located, the next step is to write your Data Services Client application.

Create the Sharepoint Application:

But first to demonstrate how easy this is, I’ve used SharePoint to create the simplest of all Suggestion Tracking applications.

You can follow along by following these simple steps:

1. Create a ‘Suggestions’ list which is based on an ‘Issues’ list.
2. Finished!

The resulting list looks something like this:

The idea is that this list will capture all the suggestions users have for making a departmental line of business (LOB) application better.

But rather than making people go to the SharePoint site to make the suggestion, we want to allow the users to do it right in the LOB application.

Talking to Sharepoint using Data Services:

The first step as always to add a service reference, using the location of the Data Service that exposes SharePoint data (i.e. http://mflasko-dev/_vti_bin/listdata.svc)

Once you’ve done this you will have CLR classes representing the types in each list, and you will have a strongly typed DataServiceContext called TeamSiteDataContext that allows you to access the data:

Rather than focusing on how the user enters the suggest in your LOB application, lets focus on how to POST that suggestion to Sharepoint.

To do that you need to write a method something like this:

public void PostSuggestion(string title, string description)
{
   TeamSiteDataContext ctx = new TeamSiteDataContext(
        new Uri(
            http://mflasko-dev/_vti_bin/listdata.svc, 
            UriKind.Absolute
        )
   );
   ctx.AddToSuggestions(
      new SuggestionsItem{
          Title = title, 
          Description = description
      }
   );
   ctx.SaveChanges();
}

As you can see this is very easy.

In an environment like Silverlight it is a little more complicated because whenever you cross a network boundary have to deal with the Async and Threading issues. Which means you can’t use SaveChanges() directly.

You have to use the standard BeginXXX() and EndXXX() async pattern and you need to use the Dispatcher to ensure the results are marshaled back on the UI thread:

In future blog posts we will dig into this in more detail, covering topic like Query / Update / Data Binding, Blob Handling and security policies over Sharepoint.

As always we are keen to hear your comments.

Alex James
Program Manager
Microsoft