Part 2 – The Solution: SharePoint 2013 Deploying List Schemas

To recap, in Part 1 the basic approach to deploying contents types via PowerShell in SharePoint 2010 and SharePoint 2013 was discussed. Now, that we have fields and content types in place lets go over the approach to deploying list schemas and instances.

We are going to be using Visual Studio 2012 to create the new list schemas and instances. When a new list schema is created in Visual Studio, there is a choice of what type of list your new custom list should mimic. Once this is selected Visual Studio provides the OOB schema, elements, and other associated form files for that particular list. Based on the documented Microsoft approach, the next step is to add your custom content type reference, content type field references, and custom views to the list schema. In the new approach, no modifications to the list schema is necessary! None. Ok… unless you are creating custom views, but we will discuss that in a bit, let’s start from the beginning.

Since the problem with updating lists after initial deployment was based on the content type and list association, we wanted to decouple that process. So, how do we associate content types to a list? Instead of modifying lines of xml in the list schema, add a list event receiver of the Event Type List Added to the list schema. This is very important, as other event types will cause timing issues with process completion. To associate a specific content type with a specific List ID, the first line in the event receiver should be an if statement that is checking to make sure that the list that is being created as a Type that matches your list. For example… If your list Type is 30000. Then the first line of your event receiver would be if (properties.TemplateId == 30000).

Once we know that this our list, based on the unique Type now the content type can be attached to the list programmatically. Also, any custom fields that need to be added to OOB or custom views should be done now as well because we cannot add custom fields to a list schema that does not have a reference for them so we must do it in the event receiver after the content type binding has taken place. Earlier I mentioned that you can create custom views in the list schema? You may want to do this if you are creating List View web parts in a site definition and you need to know the Base View ID of that view. You will want to create the views in the list schema with the proper type, URL, Name, and other basic settings but do not associate any fields other than say Title (or other OOB list fields) with them. Then the rest of the field additions happen in the event receiver. As for list instances, nothing has changed here. As long as your list instance is pointing to your custom List Schema Type and the Feature ID is pointed to the Feature that deploys your list schemas. Your good to go.

This approach have been tested with both SharePoint 2010 and SharePoint 2013. View Part 1 of this series to review the problem we are solving and how we deployed fields and content types.

Next blog will discuss customizing Calendars, Task Lists, and Picture Libraries.