I spend a lot of time creating SharePoint sites to either prove or disprove a point.  Typically I work with customers who are working with large lists and I work to isolate out the fact that the problem we are having is indeed a large list issue.  Therefore, each new SharePoint site I create, I have to populate a large list quickly to be able to prove or disprove the theory.

In classic fashion, I’ve typically used the ASMX and CAML method.  In SharePoint 2010, this code looks something like:

using (spdev.ListsSoapClient client = new spdev.ListsSoapClient())
{
   client.ClientCredentials.Windows.ClientCredential = 
      (System.Net.NetworkCredential)System.Net.
         CredentialCache.DefaultCredentials;
   client.ClientCredentials.Windows.AllowedImpersonationLevel = 
      System.Security.Principal.TokenImpersonationLevel.Delegation;

   StringBuilder sb = new StringBuilder();

   sb.Append("<Batch PreCalc='TRUE' OnError='Continue'>");

   for (int i = startAt; i <= (numberOfItems + startAt); i++)
   {
      sb.Append("<Method ID='" + i.ToString() + "' Cmd='New'>");

      sb.Append("<Field Name='Title'>Product " + i.ToString() 
      + "</Field>");
      sb.Append("<Field Name='Product_x0020_Description'>
          Description for Product " + i.ToString() + "</Field>");
      sb.Append("<Field Name='Product_x0020_Price'>" + (i * 2) 
      + "</Field>");

      sb.Append("</Method>");
   }

   sb.Append("</Batch>");

   client.UpdateListItems("Product Catalog", 
      XElement.Parse(sb.ToString()));
}

Of course, the above is actually using WCF calling the Lists.asmx service under the covers.  I still have all my necessary app.config end point configuration to worry about.

All of this happens in about 21 lines of code (minus the wrapping), most of which requires me to 1.) know the CAML that needs to be there (especially for funky columns with spaces) and 2.) build it all myself.

Let’s contrast that with the new LINQ to SharePoint found in SharePoint 2010.  I generated my DataContext class using SPMetal.  Details can be found here.

Once I’ve generated my DataContext (called SpdevLinqDataContext) I can do the same thing as above in a much simpler fashion:

using (SpdevLinqDataContext context = 
  new SpdevLinqDataContext(SiteUrl))
{
   for (int i = startAt; i <= (numberOfItems + startAt); i++)
   {
      context.ProductCatalog.InsertOnSubmit(
      new ProductCatalogItem()
      {
         Title = "(LINQ) Product " + i.ToString(),
         ProductDescription = "(LINQ) Description for Product "
               + i.ToString(),
         ProductPrice = (i*2)
      });
   }

   context.SubmitChanges();
}

The above LINQ to SharePoint took just 13 lines (again, minus the wrapping).  And, more importantly, didn’t require me to know CAML or the mechanism needed to handle spaces or any other funky characters.  Nor did I have to worry about end point configuration for WCF.

One thing to note here.  All of this was created using a Console app.  But even on a x64 machine, Visual Studio defaulted to created an x86 application.  When you attempt to run your LINQ to SharePoint code you’ll likely get an error stating:

System.IO.FileNotFoundException: The Web application at [SITE] could not be found. Verify that you have typed the URL correctly.

In this case you need to configure your app to target the x64 platform:

Both cases work of course and everyone will have their preference.

Happy coding!