Export (0) Print
Expand All

Deploy site elements by using Features (SharePoint Foundation 2010)

SharePoint 2010
 

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2011-08-05

This article describes how to deploy developed site element customizations by using Features. By using Features, you can control the scope within which the site customization can be activated and deactivated, and easily deploy the customizations across multiple server farms.

In this section:

A Feature is a container of various defined extensions for SharePoint Foundation 2010, and is composed of a set of XML files that are deployed to front-end Web servers and application servers. You can deploy a Feature as part of a solution package, and you can individually activate a Feature in SharePoint Foundation sites.

Features reduce the complexity involved in making simple site customizations. Features eliminate the need to copy large chunks of code to change simple functionality, and therefore they reduce versioning and inconsistency issues that can arise among front-end Web servers.

Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by turning on or turning off a particular Feature in the user interface.

An element is an atomic unit within a Feature. The Feature element is used in a Feature.xml file to define a Feature and to specify the location of assemblies, files, dependencies, or properties that support the Feature. A Feature includes a Feature.xml file and any number of files describing individual elements. Another Feature element from a different schema is used in an Onet.xml file to specify that a Feature be activated when a site is created from the site definition.

A Feature.xml file typically points to one or more XML files whose top-level <Elements> tag contains definitions for elements that support the Feature. Elements in SharePoint Foundation 2010 often correspond to what were discrete nodes in the Onet.xml or Schema.xml file of Microsoft Office SharePoint Portal Server 2003. There are several types of elements —for example, a custom menu item or an event handler.

  • For more information about the capabilities of Features, see Using Features (http://go.microsoft.com/fwlink/p/?LinkId=183450).

  • For specific information about the file format and XML elements used in the Feature.xml file, see Feature.xml Files (http://go.microsoft.com/fwlink/p/?LinkId=183451).

  • For information about how features affect the file format of the Onet.xml file in a site definition, see Site Definition (Onet.xml) Files (http://go.microsoft.com/fwlink/p/?LinkId=183454).

  • For more information about Feature element types, see Element Types (http://go.microsoft.com/fwlink/p/?LinkId=183455).

Features are the recommended method for deploying pieces of functionality, customizations, or configuration changes to front-end Web servers. Features are a flexible way to manage functionality through its lifecycle, including activation, upgrade, and eventually deactivation.

You can use Features to deploy developed site elements in one or more of the following scenarios:

  • Need for activation and deactivation   When you deploy site element customizations in a Feature, you can install, activate, and deactivate the Feature by using Windows PowerShell or by using the object model. You can also activate and deactivate a Feature by using the Central Administration Web site.

  • Flexibility of scope   You can activate a Feature for a single scope, including farm, Web application, site collection, or Web site.

  • Ease of distributed deployment   A Feature is easy to deploy to multiple server farms as part of a solution.

  • Control through the Feature object model   The Feature object model enables you to specify the list of installed features within a given scope and to control whether features are enabled at the farm and site levels.

Use solution packages to package Features to deploy to different environments. For example, use a solution package to deploy customizations between developer workstations and an integration farm, and also between either an integration farm or authoring client workstations, and pilot or production farms.

When you create a custom Web page in SharePoint Foundation 2010 by using the browser or SharePoint Designer, the ASPX page can belong only to the root site collection of the server that is running SharePoint Foundation 2010. To create a page under a site collection that is available to the whole farm and in all site collections, use a solution to deploy the page under the \14\Template\Layouts folder (by using the TemplateFiles element in the solution manifest file).

A best practice on a farm is to deploy Features by using a solutions package. If a server must be rebuilt or another server is added to the farm, the Feature will not have to be manually added to each front-end Web server. By using solutions packages, you can deploy new and upgraded Features across the farm and synchronize a front-end Web server so that its state is consistent with the state of other servers in the farm.

To control the availability of a custom page in a site collection or a Web site, deploy the custom Web page as a SharePoint Feature as part of a solution. Use the module element in the Feature.xml file to deploy a Web page by using a scope of site collection and Web site. Modules are frequently used to implement a Web Part Page in the site.

A Feature that is deployed as part of a solution is installed automatically. If you manually deploy a Feature, you must install and activate it. See Install and activate a Feature by using Windows PowerShell, later in this article.

To create and deploy a custom Feature
  1. Create a Feature.xml file. The following is an example Feature.xml file, which is necessary for giving the feature a unique ID and pointing to the Module.xml file.

    <?xml version="1.0"?>
    <Feature Id="8C4DD0CB-5A94-44da-9B7F-E9ED49C2B2DC" Title=
    "Custom Web page"
    Description="This simple example feature adds an ASPX page 
    with a hosted XmlFormView control" 
    Version="1.0.0.0" Scope="Web"
    xmlns="http://schemas.microsoft.com/sharepoint/">
    <ElementManifests>
        <ElementManifest Location="Module.xml"/>
    </ElementManifests>
    </Feature>
    
  2. Create a Module.xml file. The following is an example Module.xml file, which contains information about the page or pages that are part of the solution.

    <?xml version="1.0"?>
    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
        <module name="file" url="" path="">
            <file url="XmlFormViewPage.aspx" type="ghostable"> </file>
        </module>
    </Elements>
    
  3. Change the file url value to the name of your ASPX page.

  4. Add a subfolder for the Feature definition within the Features setup directory on the server computer, typically located at %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\TEMPLATE\FEATURES.

    importantImportant
    A best practice is to use detailed, qualified names for the subfolders that you create for Feature definitions. This practice minimizes the likelihood that you will add multiple Features that have the same names and overwrite the Feature.xml file for another Feature. For example, use HR_Contract and Finance_Contract rather than Contract.
  5. Add your custom .aspx page to this subfolder for the Feature definition.

  6. Add Feature.xml and Module.xml files to the same location.

  7. Add the Feature to a solution package.

    You can use Visual Studio 2010 to add the Feature to a solution, or you can manually add a FeatureManifests element to the solution Manifest.xml file.

  8. Create the solution package.

    You can use Visual Studio 2010 to build the solution package. You can also use the Makecab.exe tool to create the solution package.

  9. Import and deploy the solution package.

    Add the solution to the solution store by using the Windows PowerShell Add-SPSolution cmdlet, and then deploy the solution from the solution store by using the Central Administration Web site or by using Windows PowerShell.

For more information about using Visual Studio 2010 to add Features to a solution packages, see Creating SharePoint Solution Packages (http://go.microsoft.com/fwlink/p/?LinkId=187035). For more information about manually creating a solution package or using the Makecab.exe tool to make the package, see Creating a Solution (http://go.microsoft.com/fwlink/p/?LinkId=187036). For more information about deploying solutions, see Deploy solution packages (SharePoint Foundation 2010).

You can install and activate a Feature by using Windows PowerShell or by using the object model. You can also activate a Feature by using the Manage Web Applications Features page or the Features page of the site collection or site on which you want to activate the Feature. Installing a Feature makes its definition and elements known throughout a server farm, and activating the Feature makes the Feature available at a particular scope.

noteNote
Features that are deployed as part of a solution package are installed by the deployment and manual installation is not required.

You install Features in the 14\Template\Features folder, with each Feature in its own subfolder. At the root of this folder, a Feature.xml file defines the contents of the Feature. You must install individual Features before you can use them, and —unless the Feature is scoped to the farm — you must activate them after you install them. If a Feature is scoped to the farm or Web application, it is activated automatically.

To uninstall a Feature so that its definition is no longer available within a server farm, you first must deactivate the feature by using the Windows PowerShell Disable-SPFeature cmdlet, unless the Feature is scoped for Web applications or farms. After you deactivate the Feature, you can use the Uninstall-SPFeature cmdlet to uninstall it. For more information, see Uninstall-SPFeature. After uninstalling a Feature, reset Internet Information Services (IIS) so that the changes can take effect.

To deactivate a Feature so that it becomes inactive at its originally assigned scope without uninstalling it, you can use the Disable-SPFeature cmdlet. For more information, see Disable-SPFeature.

Use the following procedures to install and activate a Feature.

To install a Feature by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt, type the following command:

    Install-SPFeature -path <Path> [-force]
    

    Where:

    • <Path> is a valid file path; for example, MyFeature. The path to the feature must be a literal path to the 14\Template\Features folder name. The Feature.xml file name is implied and does not need to be provided.

For more information, see Install-SPFeature.

noteNote
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.
To activate a feature by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt, type the following command:

    Enable-SPFeature -Identity <FeatureID> [-url] <URLname> [-force]
    

    Where:

    • <FeatureID> is the name of the Feature folder located in the 14\Template\Features folder. It must be a valid file path; for example, MyCustom.

    • <URLname> is the Feature parent URL of the Web application, site collection, or Web site for which the Feature is being activated; for example, http://somesite.

For more information, see Enable-SPFeature.

noteNote
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft