SharePoint 2010 Code Deployment, Part One

One of the most exciting aspects of Visual Studio 2010 is the tight integration it will have with SharePoint. The Visual Studio team has worked hard to make the SharePoint developer experience much more streamlined and less dependent upon manual configuration files and custom scripts. They have also made a tremendous investment into extensibility, allowing developers to move beyond the out-of-the box features and create their own custom extensions to fit their individual or team development environment. In this series, we will explore the new code deployment functionality in Visual Studio 2010 and take a deep dive into creating our own custom deployment extensions.

Introduction

In SharePoint 2007 developers were introduced to the solution packaging framework, which gave them the capability to package multiple assets, including Features, Assemblies, files, and other elements, into a single deployable artifact. This was a tremendous step forward in terms of deployment but it still left a lot to be desired. For one thing, there was no automated way to package the solution itself – developers were required to manually create the manifest, DDF and other packaging elements, then tie them into the build process. In addition, there was no method for automatically deploying the solution package in a development environment, requiring scripts to add the package into the solution store and run the necessary timer jobs. Finally, there was a lack of integration between Visual Studio and SharePoint, such that VS had no knowledge of SharePoint items within a project, leaving developers to manage changes and updates on their own. In practice, each element of packaging and deployment existed in isolation with no direct relationship to other elements.

Legacy Packaging and Deployment

For SharePoint 2010, the Visual Studio team tackled all the issues head on with the goal of providing developers with an integrated packaging and deployment process within the IDE (as opposed to third-party solutions which plugged into the environment, such as STSDEV and WSP Builder). At the same time, they sought to overcome the primary shortcomings of the VSeWSS extensions by insuring the automated processes would be both customizable and extensible. The main objectives of the Visual Studio SharePoint deployment framework can be summarized as follows:

• Implementation of packaged code in development environment
• Modification of deployment options and parameters
• Retraction of deployed solutions    
• Elimination of repetitive manual processes which decrease productivity
• Single-click build/package/deploy process integrated into VS IDE

Although no solution is perfect, and some developers may choose to continue working with custom extensions or community tools, the packaging and deployment framework in Visual Studio 2010 does an admirable job meeting these objectives. It all begins with the introduction of SharePoint Project Items, already familiar to anyone who worked with the VSeWSS extensions, which are pre-defined SharePoint elements (such as Web Part, Workflow, List Definition, etc.) selectable from the Add New… menu within a SharePoint Project. Each SharePoint project includes a Package element which consolidates the various features, mapped folders, modules, and other project items into a WSP archive according to the directives within the Manifest.xml file (gone is the DDF file required for the MakeCab utility). The final stage, deploying the package to the local SharePoint server instance, is handled by the new Deployment framework within Visual Studio 2010.

SharePoint projects now contain a new ‘SharePoint’ tab within the project properties. This property page allows the developer to specify what type of deployment, known as a ‘Deployment Configuration’, they wish to execute. Each configuration (there are two that ship out of the box: ‘Default’ and ‘No Activiation’) consists of one or more Deployment Steps, and each step may execute one or more actions and/or SharePoint Commands. In addition, there are Pre- and Post-Deployment options for additional activities that may be required before and after the Deployment Configuration runs.

The Visual Studio 2010 SharePoint Deployment Framework

Each element – Project Items, Packaging, and Deployment – work together in a seamless process which can be automatically initiated simply by pressing F5 within the IDE. Just like ASP.NET development, Visual Studio will build, package, deploy, launch the web browser and wire-up the debugger to the worker process. This makes iterative development much easier and less fragile, eliminating a great deal of repetitive manual tasks and the potential for human error. It also lowers the rather high barrier to entry which had to be overcome by developers new to the SharePoint platform in previous releases.

SharePoint Project Items

The basic building block of all SharePoint 2010 projects is the SharePoint Project Item (SPI). Each SPI represents a specific type of SharePoint asset within the framework – web parts, workflows, list definitions, list instances, event receivers, application pages, site definitions, and so on. When a new solution is created Visual Studio automatically creates an empty feature to hold project items. If multiple items of the same type are added to a project, VS will attempt to add them to the same feature; if no features exists, it will create a new one for the selected SPI.

Visual Studio 2010 SharePoint Project Items

One critical aspect of SPI’s that warrants further discussion is the concept of conflict resolution. During the deployment process it is necessary to determine if a particular element, such as a list instance, already exists in the target site and, of even greater importance, what to do with it in relation to the code currently being deployed. Each out of the box SPI contains its own conflict resolution logic which can be toggled on and off within the item properties. If, for example, a list definition already exists, the deployment process must eliminate any list instances associated with the definition before it can retract and re-deploy the solution, otherwise the target site will quickly become littered with orphaned objects. Each SPI has different requirements which necessitate different resolution actions (web parts, for example, must be removed from individual pages and the web part gallery before the feature can be deactivated cleanly) and this logic is already included with the default items. Even better, SPI’s are fully extensible, allowing developers to define additional resolution logic or create their own logic for custom item types.

Solution Packaging

The packaging of SharePoint solutions is managed within the new visual Packaging Explorer. This utility allows developers to specify which features, mapped folders, and other assets should be included in the final WSP. By default, all SPI’s in the project which are included in a Feature, along with any mapped folders, will be automatically added to the package. The Packaging Explorer also exposes a set of advanced properties which allow for inclusion of miscellaneous assemblies, setting of SafeControl entries, and so forth. It also allows developers to drop down to the underlying XML should they wish to control the packaging process manually.

Deployment Configurations

Once a project has been built and packaged it must be deployed to the target farm, site collection or site on the local development machine. Developers control how a solution is deployed by selecting a Deployment Configuration from the SharePoint tab in the project properties. A Deployment Configuration is a collection of Deployment Steps which occur in a specified order, such as ‘Retract Solution’, ‘Recycle IIS Application Pool’, ‘Add Solution’, and ‘Activate Features’. Visual Studio ships with two Deployment Configurations out of the box – Default and No Activation. These configurations execute essentially the same set of steps with the primary difference being that the latter configuration doesn’t attempt to activate any Features after the solution has been deployed to the farm.

Developers can create their own Deployment Configurations directly in the IDE by mixing and matching any of the available Deployment Steps. There are also provisions for Pre- and Post-Deployment Commands, which allow for scripts to be run before and after the deployment process is executed. Each project can have only one active Deployment Configuration at a time but multiple projects in the same Visual Studio solution can all use different Deployment Configurations. It’s important to note that while all projects in a solution will be built and packaged, only the project marked as "Start Up" will be deployed (it is possible to have multiple startup projects within a single solution – see here).

Deployment Steps

Deployment Steps define the actual work to be done in the deployment process. In some cases, a Deployment Step has a one-to-one relationship to a pre-existing management command, such as "Add Solution", which is the same as invoking "stsadm.exe –o addsolution –filename [SolutionFilePath]" from the command prompt; however, Deployment Steps are not limited to a single activity – in reality they are task descriptors which invoke one or more commands. A Deployment Step may call an external script, invoke a custom assembly, or perform any number of assorted functions.

Visual Studio 2010 allows developers to specify which steps are included in a custom Deployment Configuration (the out of the box configurations are locked and cannot be edited) and the order in which they are to be executed during both the initial deployment process and retraction of the deployed solution. It is important to specify a valid order of execution when creating a custom Deployment Configuration, as steps which occur out of logical order can result in a failed deployment and potentially leave orphaned artifacts behind. Also, developers should be familiar with the behind the scenes actions which take place during deployment so as not to specify redundant or unnecessary steps. If, for example, a new solution is being added to the solution store using the ‘Add Solution’ Deployment Step, it is not necessary to run the ‘Recycle IIS Application Pool’ step after the solution has been added as SharePoint will automatically recycle the application pool if the solution is scoped for GAC deployment.

SharePoint Commands

Although Deployment Steps can perform any number of tasks, they are most often used to call code which interacts with the SharePoint object model. Due to the fact that SharePoint 2010 can only run on a 64-bit platform, and Visual Studio2010 is still a 32-bit application, a Deployment Step must reference a SharePoint Command assembly which is compiled against the 3.5 framework and runs in a separate process. Since they run in an isolated host process from the Visual Studio development environment, SharePoint Command assemblies can directly reference the object model and run any SharePoint-related code the developer wishes.

A SharePoint Command is executed when it is referenced explicitly by name within a Deployment Step. There are no limits on the number of SharePoint Commands that a Deployment Step can call, and a single set of commands can be shared by multiple Deployment Configurations. As such, it is important to think through the use of SharePoint Commands within a team environment. SharePoint Commands are referenced by name only, meaning that there are no type-safe restrictions in place – it is all too easy to create confusing or duplicate names for individual commands. In addition, because a SharePoint Command can run any object model methods, it will quickly become commonplace for duplicate functionality to exist in multiple commands. Although there are no "best practices" as such yet defined for the creation and use of SharePoint Commands within custom Deployment Configurations, it is probably wise to create many small classes which execute specific pieces of functionality (such as checking whether or not a solution is sandboxed or full trust, upgrading an existing solution, removing items from galleries, etc.). These commands can then be leveraged more effectively by calling them individually from within a Deployment Step.

Conclusion

Part One of this series introduces the concepts surrounding code deployment in Visual Studio 2010. In subsequent posts we will delve into how the deployment process can be customized programmatically so developers can create their own redistributable deployment extensions. Before continuing, it may be helpful for developers to learn more about the Managed Extensibility Framework in Visual Studio 2010 and Visual Studio Extensions. In order to compile and deploy the code samples, it will be necessary to install SharePoint 2010 Beta, Visual Studio 2010 Beta 2 and the Visual Studio SDK for Beta 2.

SharePoint 2010 Code Deployment, Part Two

SharePoint 2010 Code Deployment, Part Three