Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

SharePoint 2010 : Packaging and Deployment Model - Features (part 1) - Feature Designer

1/7/2013 3:39:59 PM

In a solution package, the FeatureManifest element is used to specify the reference to the manifest file for a particular feature. To a certain extent, features work in a similar way to solutions in that they can contain a number of individual components and make use of a manifest file to specify what should be done with these components.

Feature Designer

Using the Example19 project that we created earlier, double-click the Feature1 node in the Features folder to display the Feature Designer:

As you know, features are individual items of functionality that can be activated or deactivated within a SharePoint farm. You can see in the Feature Designer that features comprise one or more elements, where an element may be a web part, a list definition, a workflow, or a number of different components. Using the Feature Designer, we can select which elements should be included in a feature and therefore specify which functionality will be enabled when the feature is activated.

Activation Dependencies

For the most part, we don’t need to think about feature elements, because Visual Studio automatically creates features for us and adds our project items to them. However, in the real world, this default behavior may not be appropriate. For example, rather than having many features, each with a different project item in it, we may want to consolidate related items into a single feature. This makes it easier for users to activate our customization since they need to activate only one feature rather than many separate items. It also makes it easier for us to ensure that all the parts of our solution are activated.

We can consolidate related items in a few ways: We can use the Feature Designer to specify which elements should be included in a feature, or we can define feature dependencies. Where a dependency is defined, a feature cannot be activated unless its dependencies have also been activated. This may seem like a poor solution, because it means that users still have to activate a load of individual features, but we can take this a step further. Under some circumstances, dependency features will be automatically activated when a feature that depends upon them is activated. Furthermore, we can hide features so that they don’t appear in the feature activation user interface. Effectively, this brings us back to the idea of a single activation click for our customization, while at the same time allows us to keep individual features relatively simple.

Feature Scope

The activation dependency approach has a few limitations, but before we look at those, we need to consider feature scope. Again, this is something that we’ve been able to ignore because Visual Studio handles it for us automatically; in the real world, an understanding of scope is essential when building complex solutions.

In the Feature Designer, under the Description text box is a drop-down that we can use to select the scope of a feature: Farm, WebApplication, Site, and Web. As you’ve probably guessed, these options determine the level at which the components are activated. Components within a feature scoped as Web will be activated for a single site only, whereas components within a feature scoped as Farm will be available to the entire farm. However, it’s not quite as straightforward as that. Not all types of component can be installed in all scopes. For example, if we’re creating a content type, we can deploy it only using a feature scoped at the Site level; if we’re adding an event receiver, it can be scoped only at the Web level. You can find a complete list of what goes where at http://msdn.microsoft.com/en-us/library/ms454835.aspx.

Feature Activation Rules

To return to our discussion of the limitations of feature dependencies, the first limitation concerns scope. Features cannot be dependent on features of a more restrictive scope—that is, a feature scoped at the site collection (Site) level cannot depend on a feature scoped at the site (Web) level. This makes sense when you think about it, because a site collection can contain multiple sites, each with its own set of activated features—so there’s no way to satisfy such a dependency properly. The opposite is not true, however. Features scoped at the site level can depend on features at the site collection level. There is one caveat to this rule: A feature can’t depend on another feature at a higher scope if the higher level feature is not visible. So a site feature can’t be dependent on a site collection feature that’s hidden. There is a good reason for this: Although we can automatically activate dependent features, we can do so only within the same level. So we would be unable to activate our site feature because there would be no way to activate the site collection feature upon which it depended if the site collection feature were hidden.

The second limitation concerns dependency chains. Generally speaking, activations can be only one level deep. For example, if feature A depends on feature B, then feature B cannot have any dependencies. This is true only for visible dependencies, however. If feature B is dependent upon feature C, which is hidden, then the dependency chain is allowed. Hidden features cannot have any dependencies; therefore, the maximum chain depth is two levels.

Feature Properties

With the Feature Designer open, we can set feature properties using the Properties pane in Visual Studio. For example, we can hide a feature by setting the Is Hidden property to True. Many of the properties are set automatically by Visual Studio, but the following properties can also be used to meet specific configuration requirements:

  • Activate on Default This Boolean value dictates whether the feature should be activated when the solution package is deployed.

  • Always Force Install The SharePoint deployment mechanism is pretty clever when it comes to installing features. Because features can be shared by many solutions, only features that are not already installed are installed when a package is deployed. Each feature has a unique identifier that’s used as the reference for activation dependencies and so on. To force an installation when the solution is deployed, this value can be set to True.

  • Deployment Path All features are deployed to their own folder at %SPROOT%TEMPLATE\FEATURES\. By default, Visual Studio creates folders named ProjectName_FeatureName. In our project, our feature will be deployed in a folder named Example19_Feature1. We can change the name of this folder by changing the Deployment Path. (The name Deployment Path is something of a misnomer; it more accurately contains the Deployment folder name.)

  • Image URL & Image Alt Text In the Manage Features page, an icon appears to the left of each feature’s description. These properties can be used to specify an alternative image file and appropriate alternative text if required. In no alternative is specified, the default feature icon will be used.

We’ll look at few other properties, such as Receiver Assembly, Upgrade Actions Receiver Assembly, and Version in more detail in later sections.

Feature Elements

With a few exceptions, almost all the items we can add to a project using Visual Studio are packaged as feature elements. In our demonstration project, we added an empty element named FirstElement; in the Solution Explorer page, we can see that it contains a single file named Elements.xml. In the Feature Designer, we can click the Manifest button at the bottom of the page to see the manifest file for the feature:

<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
        Title="Example19 Feature1" Id="5fcd733e-2cc9-4363-85fd-dfe7893cb195"
        Scope="Web">
  <ElementManifests>
    <ElementManifest Location="FirstElement\Elements.xml" />
  </ElementManifests>
</Feature>


					  

Similar to how the manifest file for the solution was made up of FeatureManifest elements, we can see that the feature manifest is made up of ElementManifest elements.

Let’s add a more complex element to our project to see how this is represented:

  1. In Visual Studio, choose Project | Add New Item. In the Add New Item dialog, select List Definition and name the element SampleList.

  2. In the SharePoint Customization Wizard dialog, accept the defaults and then click Finish. A new SampleList folder will be added to the project, as shown:

If we look at the feature manifest file again, we can see that three new elements have been added:

<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
       Title="Example19 Feature1" Id="5fcd733e-2cc9-4363-85fd-dfe7893cb195"
       Scope="Web">
  <ElementManifests>
    <ElementManifest Location="FirstElement\Elements.xml" />
    <ElementManifest Location="ListInstance1\Elements.xml" />
    <ElementManifest Location="SampleList\Elements.xml" />
    <ElementFile Location="SampleList\Schema.xml" />
  </ElementManifests>
</Feature>

Two new ElementManifest elements point to the new Elements.xml files that were added and an ElementFile element. This prompts the question, What’s the difference between an ElementManifest and an ElementFile? We’ll find the answer by examining the Elements.xml file in the SampleList folder:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListTemplate
        Name="SampleList"
        Type="10000"
        BaseType="0"
        OnQuickLaunch="TRUE"
        SecurityBits="11"
        Sequence="320"
        DisplayName="Example19 - SampleList"
        Description="My List Definition"
        Image="/_layouts/images/itann.png"/>
</Elements>

In our Elements file, we’re specifying that we are creating a new ListTemplate. Our Elements file is effectively issuing a command to the deployment framework. If we open the Schema.xml file, we find much more information contained within it. The Schema file is effectively a resource file that’s used by the deployment framework to provision our list template. Another way to look at it is that our ElementManifest files dictate what should be done, whereas our ElementFile files provide the required resources to do the job.

A number of commands can be issued using ElementManifest files, and although these are mostly wrapped by a SharePoint Project Item in Visual Studio, a complete list can be found at http://msdn.microsoft.com/en-us/library/ms414322.aspx.

To get a better understanding of the significance of this, we can navigate to %SPROOT%TEMPLATE/FEATURES and then open the TaskList folder. In the folder, we’ll find a Feature.xml manifest file, which refers to the Tasks.xml ElementManifest file in the ListTemplates folder. When this feature is activated, the Task List list template is added to the list of lists that can be created for a SharePoint site. If we examine the contents of the Tasks folder, we’ll find a schema.xml file. This file defines the schema for every task list that’s currently in use on the SharePoint farm. Looking through the contents of the Features folder, we’ll find that much of the functionality of the SharePoint platform is defined here.

Other -----------------
- SharePoint 2010 : Packaging and Deployment Model - Working with Packages
- Microsoft Content Management Server Development : Validating the HtmlPlaceholderControl (part 3) - Building the Required HTML Placeholder Validator
- Microsoft Content Management Server Development : Validating the HtmlPlaceholderControl (part 2) - Checking for an Empty HtmlPlaceholderControl
- Microsoft Content Management Server Development : Validating the HtmlPlaceholderControl (part 1) - Retrieving the Current Value of the HtmlPlaceholderControl
- Windows Server 2003 on HP ProLiant Servers : Migration Case Studies (part 3) - Hewlett-Packard Company
- Windows Server 2003 on HP ProLiant Servers : Migration Case Studies (part 2) - Eastman Chemical Company
- Windows Server 2003 on HP ProLiant Servers : Migration Case Studies (part 1) - County Government Office
- System Center Configuration Manager 2007 : Network Design - Troubleshooting Configuration Manager Network Issues (part 2) - Identifying Network Issues Affecting Configuration Manager
- System Center Configuration Manager 2007 : Network Design - Troubleshooting Configuration Manager Network Issues (part 1)
- System Center Configuration Manager 2007 : Network Design - Network Discovery
- Exchange Server 2007 : Deploying a Cluster Continuous Replication Mailbox Cluster (part 2)
- Exchange Server 2007 : Deploying a Cluster Continuous Replication Mailbox Cluster (part 1)
- Microsoft Dynamic AX 2009 : Report Customization (part 2) - Adding Promotional Materials to an Invoice Report
- Microsoft Dynamic AX 2009 : Report Customization (part 1) - Creating Promotional Materials
- Leveraging the SharePoint Workspace : Edit a List Item Using the Edit Form Offline, Create a New List Item Using the New Form Offline, Synchronize Offline Changes to SharePoint
- Leveraging the SharePoint Workspace : Leveraging the SharePoint Workspace, View Your List and Display Form Offline
- BizTalk Server 2009 Operations : Disaster Recovery (part 2)
- BizTalk Server 2009 Operations : Disaster Recovery (part 1) - Configuring the Destination System for Log Shipping
- Windows Server 2008 : Promoting a Domain Controller with dcpromo
- Windows Server 2008 : Retrieving Information About Objects with dsget, Viewing and Modifying AD Permissions with dsacls
 
 
Most view of day
- Using COM to Develop UMDF Drivers : Basic Infrastructure Implementation
- Microsoft Dynamic CRM 4 : Data Migration (part 3) - Creating a CRM Adapter Publisher
- Microsoft Excel 2010 : Calculating the Mean (part 1) - Understanding Functions, Arguments, and Results
- Microsoft Exchange Server 2013 : Mailbox management - Seeking perfection halts progress (part 2) - Starting EAC
- Microsoft Systems Management Server 2003 : Patch Management - Preparing for Patch Management
- Microsoft Project 2010 : Fine-Tuning Task Details (part 9) - Viewing the Project’s Critical Path
- Windows Phone 7 : 3D Game Development (part 2) - Rendering 3D Primitives
- Windows Phone 8 : Configuring Basic Device Settings - Find My Phone
- Customizing Windows 7 : Customize the Taskbar
- Windows Server 2012 : Enabling and disabling the graphical interface in Hyper-V
Top 10
- BizTalk 2006 : Creating More Complex Pipeline Components (part 4) - Custom Disassemblers
- BizTalk 2006 : Creating More Complex Pipeline Components (part 3) - Validating and Storing Properties in the Designer
- BizTalk 2006 : Creating More Complex Pipeline Components (part 2) - Schema Selection in VS .NET Designer
- BizTalk 2006 : Creating More Complex Pipeline Components (part 1) - Dynamically Promoting Properties and Manipulating the Message Context
- BizTalk 2006 : Custom Components (part 2) - Key BizTalk API Objects
- BizTalk 2006 : Custom Components (part 1) - Component Categories, Component Interfaces
- Microsoft Access 2010 : Enhancing the Queries That You Build - Ordering Query Results, Refining a Query by Using Criteria
- Microsoft Access 2010 : Enhancing the Queries That You Build - Everything You Need to Know About Query Basics
- Microsoft Exchange Server 2010 : Getting Started with Email Archiving - Enabling Archiving (part 2) - Using Exchange 2010 Discovery, Offline Access
- Microsoft Exchange Server 2010 : Getting Started with Email Archiving - Enabling Archiving (part 1) - Archive Quotas , Exchange 2010 Discovery Operation Considerations
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro