Having only tried LINQToSharePoint (the 2007 codeplex version) a few times I decided to make a small test application of the new 2010 version, and here is the result:
I used a newly created contact list located at the root site, called EmployeeList, with 3 dummy objects for the test:
Since there is no GUI to create proxy classes, as with the early versions of LINQ to SQL, spmetal is used to create the proxy classes. Running SPMETAL with the following arguments creates the proxy classes in the Demo.LinqToSharePoint namespace:
SPMETAL /web:http://win-o6kbvml4ahk /code:DemoSite.cs /language:csharp /namespace:Demo.LinqToSharePoint
spmetal basically crawls the site you give it and creates entities for each list in the site and as with LINQ to Sql you also get a context that has the expected functionality. See msdn for a full list of command line options that spmetal takes.
Creating a visual webpart project in VS2010 and adding the newly created DemoSite.cs file is just about all it takes to test out the feature! Oh and remember to add a reference to Microsoft.SharePoint.Linq (it can be located in %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI), or you will get a lot of errors (216 in my case)
The test code to actually use LINQ to SharePoint looks like this:
public partial class LinqToSharePointDemoUserControl : UserControl
protected void Page_Load(object sender, EventArgs e)
var context = new DemoSiteDataContext("http://win-o6kbvml4ahk");
var employees = from employee in context.EmployeeList select employee.FirstName;
EmployeeListBox.DataSource = employees;
And the webpart shows:
That is about it, really easy to use and it will clearly save a lot of time, bye bye CAML! I wonder if the VS team is planning the same GUI as with LINQ To Sql, it would make this “new” feature even better!