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.
Using the Chapter 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.
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.
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.
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.
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:
We’ll look at few other properties, such as Receiver Assembly, Upgrade Actions Receiver Assembly, and Version in more detail in later sections.
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:
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:
If we look at the feature manifest file again, we can see that three new elements have been added:
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:
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.
Although covering the various resource files that can be used by features is beyond the scope of this one very important point needs to be made here: Although most of the content within a SharePoint site is stored in a content database, the same is not true for configuration. Much of the configuration for a site is defined within features, and the element files within the features are actually used to deliver the appropriate functionality.
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.
We’ve used a few feature receivers in some of the example projects in this book. A feature receiver is basically an event handler responsible for handling installation and activation eventsfor a feature. We can add feature receivers to any type of feature by right-clicking a Featurenode in the Solution Explorer pane and selecting Add Event Receiver. When we performthis action, Visual Studio adds a new code file to our project and sets the Receiver Assemblyand Receiver Class properties of the feature to reference the new code file. Let’s do this now:
In the Feature2.EventReceiver.cs file are five commented methods representing the events that can be handled by the feature receiver. By uncommenting these methods, we can add custom code to do whatever we need to do. As you embark on more complex SharePoint projects, you’ll find that although you can perform much configuration using the SharePoint Project Items available in Visual Studio, a lot of configuration still needs to be done programmatically. In these situations, the feature receiver is the tool of choice. Bearing that in mind, let’s look at how feature receivers work and how we can best make use of them.
If all is well, we’ll find that our blank demo site now contains two new lists: one named Chapter ListInstance1, which has been created by the ElementManifest in Feature1, and another named My New List, which has been created programmatically by our feature receiver in Feature 2.
Notice in this code snippet that we’re using the properties.Feature.Parent property to obtain a reference to the SPWeb object on which our feature is being installed. Some investigation of the Parent property will reveal that it’s of type object, and for that reason we’re checking its type before casting it to a variable of the correct type. To understand why this is the case, you can take a look at how features are defined within the server object model, as shown here:
Features can have four possible scopes. When a feature of a particular scope is installed, it’s added to the Features collection of the appropriate object. For example, a site collection– scoped feature would be added to the Features collection of the appropriate SPSite object. The SPFeature object that is returned by properties.Feature can therefore have one of four possible parents, depending on the scope of the feature.
To confirm that our receiver is working as expected, we can take the following steps:
Debugging Feature Receivers
Feature receivers can be difficult to debug because they are often executed within a separate process. To see an example of this problem, put a breakpoint on the first line of our FeatureActivated method and try debugging using Visual Studio. The code will be deployed and the feature will be activated, but execution will not stop at the breakpoint. Visual Studio makes use of a separate process, VSSPHost4.exe, to automate the deployment process. The Visual Studio debugger, however, is set up to attach to a W3SVC.exe process only, and therefore the breakpoint is never hit but the code still executes.
We can work around this issue in one of two ways: we can either attach a debugger to the appropriate process, or we can ensure that our feature receiver runs in the W3SVC process. To ensure that a debugger is attached to the correct process, we can take the following steps:
This technique will work regardless of the host process. For example, if PowerShell is used to install a package, the same error dialog will be displayed.
Our second option is to ensure that the feature receiver code runs in the W3SVC process. This is relatively easy to do. Earlier when we looked at feature properties, we saw that the Activate On Default value is used to determine whether a feature should be automatically installed. We can use this setting as follows:
This method works because when features are activated via the user interface, the feature receiver runs under the W3SVC process, and Visual Studio has attached a debugger to this process as part of the standard debugging mechanism.
Passing Parameters to Feature Receivers
You’ve seen how to create feature receivers and how to pick up references to the object that you need in order to access the server object model. We’ve looked at a few ways to enable debugging. Let’s move on to look at more complex feature receivers.
As mentioned, practically every real-world SharePoint project will require some custom feature receivers. This is especially true when code being developed must be shared among multiple developers or deployed to testing or staging environments. As a result, it is sensible to create a library of feature receivers that perform specific configuration tasks. For example, I have a collection of feature receivers that perform actions such as configuring security for a site or setting up search scopes. These are actions that are common to many SharePoint projects but that can’t be performed declaratively.
One essential aspect of creating reusable feature receivers is the ability to pass configuration into the receiver.
Let’s look at a few ways to solve this problem. The first method is appropriate if a collection of name/value pairs is sufficient for our purposes.
Although every element in a feature has a Feature Properties property, in reality the properties are applied at the feature manifest level—that is, the combination of all the properties that are added to each element in Visual Studio are actually written within a single Properties element in the feature manifest.
You can see that we’re able to address the properties via the properties.Definition object. The Definition object is of type SPFeatureDefinition and is an object representation of the various XML elements that make up the feature.
The next method for solving the problem is appropriate if more complex configuration is required. For example, when configuring security settings for a site using a feature receiver, I use this approach to load an XML file containing the security configuration.
When we deploy the solution and activate the feature, three new lists will be added to the site as specified in the MyConfig.xml file. In this example, we’ve used an XmlReader to parse the configuration file for the sake of keeping the example simple. In a real-world solution, using an XmlSerializer to deserialize the configuration file into an appropriate collection of objects would be more robust.
In SharePoint 2010, one of the important new capabilities from a packaging and deployment perspective is the ability to upgrade features. In previous versions, an upgrade was possible, but it was more a case of replacing an old feature with a new version. This could leave a system in an indeterminate state, because actions performed by the old feature would not necessarily be undone when a new version of the feature was installed.
For example, if a feature created a list that users subsequently populated with data and then a new version of the feature created a new version of the list with a different name, the result of deploying the new feature would be two lists. A better approach would be to rename the old list.
With the upgrade capabilities in SharePoint 2010, we can define a number of upgrade actions declaratively in the feature manifest, and for more complex upgrade processes we can also use a feature receiver to make any changes programmatically.
We can trigger an upgrade in a few different ways, including using the psconfig tool to upgrade all features within a farm. This tool is useful when many features have been updated, since it’s a pretty lengthy process. For example, if a service pack updates many system features, running psconfig will ensure that instances of the updated features are upgraded where appropriate.
Let’s look at several possible psconfig commands. This command performs a version-toversion upgrade:psconfig.exe -cmd upgrade -inplace v2v
Feature versions are in the format major.minor.build.build. When using a version-to-version upgrade, only features in which the major or minor version number has changed will be upgraded. So for a feature with version 184.108.40.206, if we deploy a new build with the version 220.127.116.11, no upgrade will be performed. However, if we deploy version 18.104.22.168, an upgrade will be performed because the minor version number has changed.
This command performs a build-to-build upgrade:psconfig.exe -cmd upgrade -inplace b2b
By using this mode, we ensure that any changes to the version number will trigger an upgrade. So, for example, version 22.214.171.124 will be upgraded if version 126.96.36.199 is deployed.
A quicker way to upgrade an individual feature instance is to use PowerShell. Follow these steps to see the upgrade process in action:
By attaching this XML to the feature definition, we’re defining the steps that should be taken to upgrade existing features. The CustomUpgradeAction element specifies that we’re using a feature receiver to perform the upgrade programmatically. In this example, we haven’t specified a version range, so this upgrade action will apply for all versions. If we needed to include different upgrade actions for different versions we could add this:
NOTE Within the Properties pane are options to set the Upgrade Actions Receiver Assembly and Class properties. These properties allow a feature to use a separate assembly for handling standard feature events such as Activate and Deactivate and a separate assembly for handling upgrade events. This facility is useful for retrofitting upgrade capabilities to a feature if the existing receiver assembly isn’t available or can’t be altered for some reason.
Notice the use of a switch block in this code snippet to handle the upgradeActionName. This value is specified in the Name attribute of the CustomUpgradeAction element in the feature manifest.
NOTE This command should be entered as a single line.
if all is well, the resultant output should be this:Current Version: 188.8.131.52, Latest Version: 184.108.40.206
Version The new version number should be reported as 220.127.116.11.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.