SPC’09: Visual Studio 2010 SharePoint Development Tools Overview

Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood.

This session was given by Mike Morton, from Microsoft, and it focused on an overview of the new Visual Studio 2010 features for SharePoint Development. It was a demo intensive session, but very effective in showing how much easier SharePoint development will become with these new tools.

Debugging got a lot easier with the new SharePoint project templates of Visual Studio 2010 which all automatically create Packages (WSP files, previously called SharePoint Solutions) and associated Features, and allow one-click deployment to SharePoint.

Mike introduced the concept of SharePoint Project Item (SPI), which represents every possible artifact you might want to develop for SharePoint, from SharePoint Workflows to List Event Receivers, and from Web Parts to List Templates.

Using Visual Studio 2010, you can add an SPI to the SharePoint project when you want to create one of those artifacts. Visual Studio will automatically create the necessary files to package that artifact (which can be Feature Manifests, Resource Files, Element Manifests or Class Files) and updates the Package Manifest.

In addition to automatically creating all the XML files for Features and Packages, Visual Studio includes the Package Designer and the Feature Designer which allow you to graphically edit the contents of a package and the elements included in a feature, respectively. SharePoint deployment will never be the same again…

Other new concepts:

  • Visual Web Part: an SPI that allows you to develop a Web Part using a Visual Designer, like if you were a creating an ASP.Net page. This was a really welcome addition 🙂
  • SharePoint Root: previously called “Hive” or “12 Hive”, it should now be called SharePoint Root. You can use the token {SharePointRoot} to point to this folder which can be either a physical folder in the server’s hard drive (like the previous “Hive”) or some location on the SharePoint database (for Sandbox Solutions).
  • Mapped Folders: SharePoint folders (inside the SharePoint Root Folder) that are mapped in your SharePoint Project as virtual folders. All files that you place inside these folders will then be placed inside the project package when Visual Studio generates it (e.g. Layouts folder, Images folder, …).

Visual Studio 2010 has a new project template which allows you to Import an Existing SharePoint Package (WSP file) and build a new deployment project with the components of that package that you select. This project template will also analyze dependencies between the components so that your new deployment package contains all the required components (and not only the ones you selected). The great thing is that, this WSP file you are importing could have been exported by SharePoint Designer or the result of a Save Site as Template action in the Web UI.

When you press the deploy button on Visual Studio (or press F5 to Debug a SharePoint project), it will perform the following actions, by default:

  • Pre-deployment actions (scriptable actions)
  • Recycle application pool
  • Retract package
  • Add package
  • Activate features
  • Post-deployment actions (scriptable actions)

You can, however, customize the deployment steps to include less steps or even develop you own steps by extending Visual Studio.