The new support for LINQ in SharePoint 2010 makes it much easier to read and write data to/from SharePoint lists. The way it works is that you run a utility SPMETAL.EXE to generate the entity model that is used as the context for the queries. Quite helpful but it only includes the fields (the data types in SharePoint like “single line of text”) that are out-of-the-box in SharePoint Foundation 2010.
Other fields added by SharePoint Server 2010, field types added by third parties, or custom field types you might create won’t show up in the entity model generated by SPMETAL.EXE. This can be challenging to work with some of the more common field types such as those included by SharePoint Server 2010.
This can be a bit frustrating as the LINQ model you generated isn’t a match for your list when you are working with something like the Managed Metadata column. Thankfully there is a very easy way you can extend a SPMETAL.EXE generated entity model.
Consider the following: I’ve created a custom contact list . I added a metadata field named Location Tag to it using a Feature receiver that calls the method you see in Figure 1.
Next, I generated the entity model by running SPMETAL.EXE against the list. At this point it does not include my custom field Location Tag.
Next create a partial class that matches the name of the entity generated by SPMETAL.EXE. In my case this is ContactListWithAutomaticTagsContact.
Have it inherit from the same type as the entity model does (Contact). (See Figure 2.)
To include the field in the entity the next step is to have the ContactListWithAutomaticTagsContactclass implement the ICustomMapping interface.
This includes three methods shown in Figure 3 that map the data to the field & vice versa as well as resolve any conflicts.
With this you’ll now have full access to your custom field type, in this case the TaxonomyField, within LINQ queries (see Figure 4).