Practical .NET

Deploying Lists in SharePoint with Visual Studio 2010

Since the best tool for creating a list is SharePoint itself, why not take advantage of it when deploying a new list to your SharePoint solution? Visual Studio 2010 lets you do that.

• By Peter Vogel
• 07/19/2011

Every year, one of my objectives as a SharePoint developer is to do a little less coding in CAML than I did the year before. I'm hoping that, someday, the only place where I will actually have to generate CAML code is in issuing queries -- and LINQ plus the descendants of spmetal may even eliminate that. The most recent place where I've eliminated CAML from my life is in creating lists.

In SharePoint, you have three ways to add a list to a SharePoint site: CAML, code and the SharePoint user interface. Using CAML requires you to define your list in the Schema.xml file -- intimidating, to say the least. The code to add a list to a SharePoint site is relatively straightforward, provided that you intend to use one of the existing templates without modification. Once you start customizing the list's structure things start to get complicated.

But let's think about when you need to create a list. Obviously, you're going to need to create the list in your development copy of SharePoint as part of building your feature... and you'll probably use the SharePoint UI, rather than CAML or code, to create that list. The sad fact is that, absent a SharePoint list designer in Visual Studio, the best tool for creating a SharePoint list is SharePoint.

So the only time that you're going to need to create a list using CAML or code is when you "re-create" a list as part of deploying to production. If you're only deploying to one production site then the appropriate choice might be to just sit down and create the list in the production site using the SharePoint UI (which is what I suspect most SharePoint developers do). There's some risk here because the list you create in production during deployment might not match the list in your development system. The alternative is, in your development system, to laboriously build some set of CAML or code that recreates the list you've already defined in your development system using the SharePoint UI. While that process will certainly reduce the risk of having the list defined incorrectly in production, it's also going to take up a lot of your time.

If re-creating the list in the SharePoint UI as part of deploying your solution isn't an option, then Visual Studio 2010 (the first version of Visual Studio to actually support SharePoint development) has another solution: importing WSP files. This lets you create your list in SharePoint (the best tool) and then transfer it to Visual Studio where you can include it in your solution.

The first step, after creating the list in SharePoint, is to export it -- and the rest of the site -- using the "Save site as template" choice in the Site Actions section of the site's Site Settings page. That adds a site template to the site's Solutions gallery where you can download it as a wsp file.

The next step is to import the wsp file Into Visual Studio 2010. You can do that by creating a new project using File | New Project and selecting Import SharePoint Solution Package. As part of creating that project, you'll have the opportunity to browse to the exported wsp file and select it.

Visual Studio then displays a list of all of the items in the template, all of which will be selected for importing. Since this will normally be a lot of item, the easiest way to reduce it to just the items you want is to first select all of the checkboxes by using Ctrl_A and then uncheck the first checkbox -- all of the checkboxes will be unchecked. You can then scroll through the list and check off just the items that you actually want to import.

There's a couple of more button clicks involved to get the project set up but, once you're clicked them, you'll have all the CAML that you need to deploy the list. There's typically more Features defined in the project than I want, so I usually delete all but one and combine everything in the project into one Feature (also easy to do in Visual Studio 2010); but that step isn't essential. You now have a SharePoint solution that will reliably deploy to production the same list you tested with in development.

And, as an extra benefit, the resulting Visual Studio project will make everyone think that you actually know CAML.