It's finally here: LINQ to SharePoint 0.2.4.0 Alpha. This is our first official release targeting Visual Studio 2008 and .NET Framework 3.5 RTM.

What's new in this release?

The focus for this release was primarily on getting the bits ready for Visual Studio 2008 RTM. Although there were no major API changes between Orcas Beta 2 and Orcas RTM that affected LINQ to SharePoint, we needed to validate quite some things.

While working on entity updating support in a separate prototyping branch (something planned for v0.3, which will be our first Beta, planning TBD) a few bug fixes made it in this alpha.

One major point of focus was reducing the dependencies by introducing a provider model. In the past alphas, there was a strong dependency on Microsoft.SharePoint, aka the SharePoint Object Model. Normally, this assembly is only available on machines where Windows SharePoint Services is installed. Using LINQ to SharePoint previously introduced the need to redistribute this assembly because:

• we had a few internal dependencies on it in the parser;
• the generated data context object had a constructor taking in an SPSite object.

First of all, we eliminated the dependencies in the parser, making the parser "provider-agnostic". Next, the communication layer was divided into two pieces:

• a webservice based provider, which is integrated in BdsSoft.SharePoint.Linq;
• a SharePoint Object Model based provider, that lives in a separate assembly called BdsSoft.SharePoint.Linq.ObjectModelProvider.

By default, we only import BdsSoft.SharePoint.Linq which uses webservice communication and doesn't depend on Microsoft.SharePoint. If you want to use the SharePoint Object Model you'll need to opt-in for it explicitly. Since the SharePoint Object Model can be used only on the local machine where WSS is installed, you'll have the Microsoft.SharePoint assembly over there anyhow.

The way this looks in the Entity Wizard is shown below:

This checkbox has to be explicitly marked if you want to use the SharePoint Object Model. It causes the SPML to include an attribute that switches on the SharePoint Object Model data provider (click to enlarge):

When generating the code for the SPML definition, we'll emit an additional constructor that supports the SharePoint Object Model (click to enlarge):

Under the covers, the SharePointDataContext base class has a constructor overload accepting a Uri (for the web services provider which comes with the LINQ to SharePoint main assembly) and one that takes in an ISharePointDataProvider, a new interface that abstracts away the underlying provider implementation. Theoretically 3rd parties could implement another provider but the Entity Generator tool won't be aware of it (theoretically we could have provider registration stuff in the registry and load the provider list dynamically, asking it to generate the desired constructor overloads, etc but we don't expect there's a big need for additional providers - tell us if the assumption is wrong!).

Only if the SharePoint Object Model provider was enabled, we'll import the required assemblies for you:

Notice our setup package that integrates with Visual Studio 2008 includes these assemblies but the goal of this feature is to reduce the runtime (and deployment) dependencies.

For the SPMetal freaks we have an -enablesom flag that does exactly the same as the wizard:

Download now

Get it here: LINQ to SharePoint 0.2.4.0 Alpha. Notice all usual disclaimers apply; this software is still alpha quality so we don't make any guarantees whatsoever concerning the functional or quality.

Enjoy!