SharePoint: SharePoint to Linq pitfall

Today I came across a dangerous pitfall when working with Linq for SharePoint 2010. For those of you who are not familiar with it; there is a tool called spmetal you can use to generate a Linq DataContext class for your SharePoint site. This works pretty good; you can use the Server Explorer to browse to your SharePoint site, select a list you want to query, right click it and choose “Generate Entity classes”.

What this does is generate a class for you, which you can then use with Linq to query that list, insert items, etc.

So where’s the pitfall you might ask? Well some things don’t seem to play well with localized solutions. Today I was working on a project in which localized features create things like content types and lists on a SharePoint site. This means the lists have different titles, and that causes problems with the generated Linq datacontext.

Querying items

One thing you probably want to do is stuff like:

var test = context.ListName.Where(l => l.Title.Contains(“test”)).SingleOrDefault()

This will fail in sites in a language different then the one you used to create the Linq datacontext. Why? Because the Linq class uses the name of the list to retrieve it. Sounds kind of silly? My thoughts exactly. I have no clue why Microsoft would have chosen for such a model, with all the problems it creates. A better way would be to use the relative URL of the list, or the ID. Site admins can quite easily change the title of a list and thereby break your solution.

Workaround

Ok so now what? Well there is a workaround. First get a regular SPList object from your site. This you can do by ID or, like I’m doing, by relative URL:

SPList list = web.Lists.GetList(“/site/Lists/ListAddress”);

now use the Title property of this list with your datacontext, as such:

var test = context.GetList<Item>(list.Title).Where(l => l.Title.Contains(“test”)).SingleOrDefault()

This way, the correct title is passed to the datacontext and thus it will retrieve the correct list. It’s not ideal, but it works. I really hope Microsoft will improve the Linq to SharePoint capabilities in SharePoint vNext. I know the team which worked on the Linq2SharePoint Codeplex project was adopted by Microsoft, so I hope that means they’ll do a better job in the near future.

Related posts

Long Term Support… or not?

Today I came across a dangerous pitfall when working with Linq for SharePoint 2010. For those of you who are not familiar with it; there is a tool called spmetal you can use to generate a Linq DataContext class for your SharePoint site. This works pretty good; you can use the Server Explorer to browse to your SharePoint site, select a list you want to query, right click it and choose "Generate Entity classes".

What this does is generate a class for you, which you can then use with Linq to query that list, insert items, etc.

So where's the pitfall you might ask? Well some things don't seem to play well with localized solutions. Today I was working on a project in which localized features create things like content types and lists on a SharePoint site. This means the lists have different titles, and that causes problems with the generated Linq datacontext.

[DevOps] Should you migrate onto YAML release pipelines?

Today I came across a dangerous pitfall when working with Linq for SharePoint 2010. For those of you who are not familiar with it; there is a tool called spmetal you can use to generate a Linq DataContext class for your SharePoint site. This works pretty good; you can use the Server Explorer to browse to your SharePoint site, select a list you want to query, right click it and choose "Generate Entity classes".

What this does is generate a class for you, which you can then use with Linq to query that list, insert items, etc.

So where's the pitfall you might ask? Well some things don't seem to play well with localized solutions. Today I was working on a project in which localized features create things like content types and lists on a SharePoint site. This means the lists have different titles, and that causes problems with the generated Linq datacontext.

Latest posts

Long Term Support… or not?

Today I came across a dangerous pitfall when working with Linq for SharePoint 2010. For those of you who are not familiar with it; there is a tool called spmetal you can use to generate a Linq DataContext class for your SharePoint site. This works pretty good; you can use the Server Explorer to browse to your SharePoint site, select a list you want to query, right click it and choose "Generate Entity classes".

What this does is generate a class for you, which you can then use with Linq to query that list, insert items, etc.

So where's the pitfall you might ask? Well some things don't seem to play well with localized solutions. Today I was working on a project in which localized features create things like content types and lists on a SharePoint site. This means the lists have different titles, and that causes problems with the generated Linq datacontext.

[DevOps] Should you migrate onto YAML release pipelines?

Today I came across a dangerous pitfall when working with Linq for SharePoint 2010. For those of you who are not familiar with it; there is a tool called spmetal you can use to generate a Linq DataContext class for your SharePoint site. This works pretty good; you can use the Server Explorer to browse to your SharePoint site, select a list you want to query, right click it and choose "Generate Entity classes".

What this does is generate a class for you, which you can then use with Linq to query that list, insert items, etc.

So where's the pitfall you might ask? Well some things don't seem to play well with localized solutions. Today I was working on a project in which localized features create things like content types and lists on a SharePoint site. This means the lists have different titles, and that causes problems with the generated Linq datacontext.

Leave a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *