SharePoint Application Lifecycle Management

Editor's Note: This is an excerpt from SharePoint Designer 2010 Unleashed, by Kathy Hughes (SAMS: 2011), and appears courtesy of the publisher. To learn more, see the book’s website.

The application lifecycle management in SharePoint 2010 means that both developers and designers can now work across the board when designing and deploying customizations. The WSS Solution Package (WSP), introduced as part of SharePoint 2007, has been extended to include sandboxing and more portable characteristics such as the ability to import WSP files into Visual Studio 2010 from SharePoint Designer 2010.

Another major step forward is enhanced upgrade features, including a visual upgrade from version to version. In other words, when you upgrade from SharePoint 2007 to SharePoint 2010 you have the option to keep the 2007 user interface.

Sandboxed Solutions

Solutions were introduced in SharePoint Server 2007 as a means for deploying and managing customizations in SharePoint sites, such as custom Web parts, Features, Site Definitions, master pages and page layouts. Solutions are a CAB-based file format, but with a .WSP extension, also known as a SharePoint Solution Package.

In SharePoint Server 2010, solutions have been enhanced to add additional security features, such as sandboxing and validation framework. A new concept, user solutions, means that site collection administrators now have greater control over activating and deactivating solutions for site collections.

Sandboxed solutions introduce a new security model around working with and deploying server-side coding solutions. Sandboxed solutions also better safeguard production servers against malicious code. You can now upload a .WSP file directly into SharePoint instead of having to deploy it as a full farm solution where you would typically need to go onto the actual SharePoint server and run PowerShell or the STSADM command-line tool to deploy it.

SharePoint 2010 gives you the option to upload a .WSP file directly to a site collection’s Solutions gallery where Sharepoint loads it via a locked-down process and then monitors and restricts that process using Code Access Security (CAS). If the code abuses the environment, such as using too many resources, then it can be automatically shut down depending on the configuration that has been set by the server administrator.

Figure 2.18 shows the sandboxing option available in Visual Studio 2010 when packaging and deploying SharePoint 2010 solutions.

Solution galleries reside at the root of site collections and enable site collection administrators to upload, activate, deactivate, and upgrade solutions via the user interface. Solution galleries replace the Site Template gallery in SharePoint 2007; additionally, site templates, with a .STP file extension, are not supported in SharePoint 2010. See Chapter 8 for further information on how to upgrade existing .STP files.

Features

Features, with a capital F, were introduced in SharePoint Server 2007 and offer reusable plug-and-play functionality throughout SharePoint site collections and sites, including the option to turn on or turn off certain options. When factoring in deployment options for customizations, Features provide a means for deploying uncustomized versions of master pages, CSS files, and page layouts. Also, Features enable you to push out new functionality to existing SharePoint sites, such as additional ribbon and list item menu (LIM) commands.

NOTE: If you are not already familiar with the concept of customized and uncustomized pages in SharePoint sites, by default uncustomized pages refer to those pages that derive directly from the Web front-end server and have not been modified and saved to the SharePoint content database using SharePoint Designer 2010.

On the other hand, customized pages refer to those pages that have been modified and saved to the SharePoint content database using SharePoint Designer 2010. A common scenario for deploying uncustomized design artifacts, such as master pages, is to design and create pages in SharePoint Designer 2010 but deploy those pages using a Feature.

Features enable developers to push out and add changes to existing SharePoint sites (also referred to as Feature stapling). In other words, where you’ve created a site based on a particular site template (such as the Team site template) but then want to add extra menu items into those sites. This could easily be achieved by creating and deploying a custom Feature to the SharePoint 2010 Web front-end server.

Custom Features are typically created and deployed using a Solution in Visual Studio 2010, so the role of creating custom Features typically falls on that of a SharePoint Developer. A number of out-of-the-box Features are deployed when SharePoint 2010 is installed, to provide core functionality throughout SharePoint sites and site collections, such as a Feature to provision document libraries throughout SharePoint site collections.

Features are physically located on the Web front-end server under the FEATURES folder in the 14 Hive, at %SystemDrive%Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATEFEATURES. The 14 Hive is the location for SharePoint system files. It includes all of the out-of-the-box Features, site templates, CSS files, and master pages and other global files. Previously, in SharePoint 2007, system files were stored in the 12 Hive.

Each Feature must contain a feature.xml file, which includes declarations for Feature scope, such as whether a Feature is made available to an entire Web application, site collection or Web (site) and other values, including a GUID that uniquely identifies each Feature, as shown in Listing 2.1. Features can also contain dependencies, such as .ASPX pages and other files, including an elements.xml file.

LISTING 2.1 DocumentLibrary Feature.xml File

Within a SharePoint deployment, Features can be scoped, or made available, to one of four levels within a SharePoint deployment, including farm, Web application, site collection, or Web (site) level.

This enables SharePoint administrators to more easily control what functionality is made available to entire Web applications or limit Features to a particular site collection or subsite (when working with Features, a subsite is defined as a Web). Table 2.2 outlines the different Feature scopes.

Before a Feature can be consumed, or used, within a site collection or subsite, that Feature needs to be activated (or turned on). When SharePoint sites are provisioned using out-of-the-box site templates, such as the Team site template, many Features are deactivated by default and additional functionality is not made available within a site until a Feature is activated.

For example, by default, a Team site provisioned within a SharePoint Server 2010 environment does not automatically activate the site collection SharePoint Server 2010 Office SharePoint Server Publishing Feature. Activating the publishing Feature provides additional publishing functionality, including related publishing Pages and Images document libraries and a Workflow Tasks list. When developers create custom site templates, they might choose which Features are activated by default upon site creation.

Figure 2.19 shows the Site Features page available via the Web interface, where Features can be activated or deactivated.

NOTE: A developer may also choose to hide Features from the Web interface, in which case those Features may only be activated or deactivated using PowerShell or the STSADM command-line tool.

Feature Dependencies

Additionally, Features may contain nested, or dependent, Features by using the ActivationDependencies declaration within the feature.xml file. For instance, the subsite level publishing Feature fails to activate if the site collection publishing Feature has not been activated first. Listing 2.2 shows an example of a Feature dependency in the PublishingWeb Feature, which has dependencies on other publishing Features before it can be activated.

LISTING 2.2 PublishingWeb Feature.xml File Showing ActivationDependencies

If you attempt to activate a Feature that hasn’t met ActivationDependencies as defined in the feature.xml file, the Feature fails to activate. Figure 2.20 shows what happened after an attempt to activate the publishing Feature on a subsite before activation of the site collection publishing Feature.

NOTE: Publishing Features are referred to throughout the book and are sometimes simply referred to as a site collection, site or subsite publishing Feature, as applicable, rather than the full Feature name shown on the Site Settings page.

Similarly, the Business Intelligence site template within a SharePoint Server 2010 site is not visible until the PerformancePoint Services Site Collections Features is activated.

Using SharePoint Designer 2010, you can create a code-free Feature by using the Custom Actions option available in lists and libraries to create new buttons and commands in the ribbon and LIM. See Chapter 28, “Creating Custom List Actions: Adding Buttons to the Ribbon and List Item Menus,” to learn how to utilize the Custom Actions option and also how to also use Visual Studio to create a custom Feature to extend ribbon commands.

Kathy Hughes is a Microsoft MVP for SharePoint Server with a Masters Degree in interaction design from the University of Technology in Sydney, Australia. Hughes trains and consults on SharePoint, focusing on design, usability, and customization. She contributed to multiple SharePoint Server 2007 books, and authored a comprehensive five-day SharePoint Server 2007 Designer course used by Mindsharp and its partners worldwide. She speaks regularly at Microsoft events including TechEd Australia and Office DevCon Australia.