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.

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.

About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in Web development with expertise in SOA, client-side development, and user interface design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on language and technical writing can be found at rtfmphvis.blogspot.com.

comments powered by Disqus

Reader Comments:

Wed, May 16, 2012 Jas Kauldhar Canada

Creating custom list in SharePoint and Visual Studio is probably the most difficult part of developing in SharePoint. However, once you have it mastered the benefits of what you can do far out-weigh importing .WSPs, reverse engineering or any other method. Learn it once - you'll be better off.

Wed, Jul 27, 2011 Peter Vogel Canada

Robin: I think there's a real good case to be made for using the SharePoint object model to implement changes. I do that a lot myself (though not for list definitions). I then drop the code into a Feature Activated event so that the code will make the changes when the site admin activates the feature. I do have to admit that I'm always concerned about home grown frameworks unless they are used exclusively by the developer who creates them, though. I think these frameworks are an important part of a developer's toolkit but these tools tend to be idiosyncratic (and I speak as someone who's built more than a few for myself).

Wed, Jul 27, 2011 Robin Hood Washington, DC

After developing custom SP solutions for a few years now, I've learned that creating lists in SP and "reverse-engineering" them eventually gets complicated as the project progresses. For instance, after you've deployed to production and the client wants changes to be made, it's difficult to modify all that CAML, and sometimes impossible to make simple changes such as renaming fields. Additionally, I've learned that developing against SP requires some best practices such as using static names for fields that don't mimic the display names, as your code needs to be able to find fields by a static name that you know the users haven't changed. Creating lists either in CAML or in SP itself makes this difficult. And frankly, working with all those GUIDs gives me a headache. I've found that the SP object model, though still buggy and difficult to work with, makes it easier to develop redeployable lists, content types, etc. On some projects I've used simple helper classes that contain a bunch of static methods like CreateList() and AddLookupField(). What's better, though, is a home-grown framework I've used in the past and have recently brought back to life on my current project. I define lists in an XML file--which uses own schema that evolves as we need it to--and have some code that reads the XML file and creates from it the specified SP objects. The best part is that it is smart enough to add new content types/lists/fields or update existing ones as necessary, so updating an existing solution is a cinch. Creating a semi-complicated list structure takes only a few minutes and is done in the development environment first--where development is supposed to begin.

Tue, Jul 19, 2011 Peter Vogel Canada

Spaxeman: Your point about content types is a good one (one I should probably have mentioned). I generally keep a site that I use (almost) exclusively to develop lists and I export from that site. I also, of course, define the content types that those lists need in that site also. That helps keep my number of items I have to select from small when exporting. I then export my lists from this site. I haven't run into your re-exporting problem and it's probably because I'm always exporting from my "list site."

Tue, Jul 19, 2011 spAxeMan

There is one caveat that I might add (please note that I am a nube SP dev but have been thrown in the deep end with SP2010). I have often gone down the path of trying to save the project template wsp file and only trying to import what I need. I have often run into one of 2 problems: - There are items that are dependant on content types, which if left unselected will prompt an error by VS2010. Trying to resolve them through that VS2010 template UI with no visibility of what I am selecting is awful (often I give up and simply check everything) - The other issue to be aware of is an annoying (and possibly a bug) issue which occurs when you recursively nest site templates witin each other (export a site template> new site collection based on template > re-export as another site template .....(2 are usually enough)). In this case trying to re-import some items into VS2010 causes an import error becuase now it complains that folder names exceed a 260 char limit. I find this is happening because VS2010 for some reason imports and simply concatenates all strings along a feature path into a massive long string > 260 chars. I then sometimes have to manually correct this all over the project

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.