Microsoft SharePoint 2007 Development – Features and Solutions

I thought of publishing all the Technical Articles I write for Magazines in my blog as in someway it’ll help the readers. Article below was written in the month of November for online magazine Digit. It’s the second article of the series Microsoft SharePoint 2007 Development.

You can find the 1st Article here.
Please click on the images for the larger preview.

Another cold, dark and cloudy day with thundering showers in the month of November. What else can come to my mind rather going to bed? Oh! the second article of the series, SharePoint 2007 Development. Hope you had a chance to go through the first article “SharePoint Object Model” which is an introduction to SharePoint Object Model.

This article doesn’t cover what SharePoint is or its usage. Targeted audience is the programmers who are already familiar with SharePoint who’s looking for an introduction to “Features” and learn how to access “Features” with SharePoint Object Model.

What is a Feature?

What exactly is a feature and why is it called a feature? Isn’t it bit awkward to talk about the “Feature” feature? :)

The Feature is a container of various defined extensions for SharePoint. It’s a set of XML files which are deployed to Web Front Ends (WFE) servers in a farm that can be bundled in site definitions or individually turned on in SharePoint sites. The ability for sites to use the functionality in other sites easily is provided by features. Features has eliminated copying and pasting of huge chunks of XML from one template to another. Features have a scope, and can be associated with various scopes in SharePoint: web, site, web application, or farm. Depending on the scope, different types of individual elements can be defined in XML.

What is a Solution?

Solutions allow to package features in a cabinet file (.cab) and store important metadata about the features. After a Solution is installed on a server in the farm, you can then use SharePoint’s Solution management features to automate the deployment of that Solution to other sites within the farm.

Great, now you have a basic understanding of what a feature is and what a solution is in SharePoint. As the next step I’m going to deploy a feature in to a MOSS 2007 (Microsoft Office SharePoint Server) server.

Creating a Simple Feature

This example steps you through the process of creating a custom action Feature that adds a button to the toolbar of the form for editing announcements items within the scope of a SharePoint site. Example below is taken from Windows SharePoint Services SDK.

Create a subfolder called SimpleFormToolbarButton folder under Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES in your MOSS Server.

Best way to do this without worrying about the permission issues is to create the folder in command prompt. Type cmd in Run, hit the Enter key. Browse to the Features folder and type md SimpleFormToolbarButton which will create a subfolder with the given name.

Next step is to create the feature.xml with in the newly created folder. So create a new file with the name feature.xml and type/paste the content below.
 
Open the file within Visual Studio, but one thing you will notice is there is no IntelliSence. Click on Schemas in file properties. You will see a window to select a XML schema file. Browse to the XML folder under Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE, select the wss.xsd file to enable IntelliSence for the feature.xml.

To replace the GUID placeholder in the previous Id attribute, generate a GUID by Tools > Create GUID > Registry Format and click on copy button.
 
Your code should look like above (with a different GUID). Next Create an Elements.xml file in the SimpleFormToolbarButton folder that points to an .aspx file, such as the following, which uses the CustomAction element to define the custom action.
 
To test the sample feature, create a SampleUrl.aspx page such as the following that displays "Hello, world!" and place it in the TEMPLATE\LAYOUTS directory.

 
Okay, let’s install the feature in the deployment server and activate it on a specified subsite. Go to the command prompt and type the below command for installation. Make sure to be within the Features folder.

stsadm -o installfeature -filename SimpleFormToolbarButton\Feature.xml

Activation can be done through the UI or through the command prompt. We’ll use the second method.

stsadm -o activatefeature -filename SimpleFormToolbarButton\Feature.xml -url http://Server/Site/Subsite

To try out the new button, navigate to the form for editing an existing announcements item. Great, if you followed me, you have successfully created, deployed and activated a simple feature. Image below show the customized toolbar with the link “Simple”.

Now is the time to play with the Object Model. SharePoint includes a robust object model for working with Features that allows developers to enumerate installed and activated Features, to turn Features on and off, and to control the installation or removal of Features.

Object Model for Features

Given below are the key classes.

§ SPFeatureCollection/SPFeature—Refers to a Feature state at a given site hierarchy level. The presence of a SPFeature instance within a property of type SPFeatureCollection indicates that the Feature is active at that level.

§ SPFeaturePropertyCollection/SPFeatureProperty—Represents a single property on a Feature or a collection of those properties.

§ SPFeatureScope—Represents an enumeration of the possible scopes in which Features can be activated. Possible values are: Farm, WebApplication, Site, and Web.

§ SPFeatureDefinition—Represents the basic definition of a Feature, including its name, scope, ID, and version. You can also store and retrieve properties of a Feature. Note that Feature properties apply globally to a single Feature definition, not to instances of Features activated throughout the farm.

§ SPFeatureDependency—Represents a Feature upon which another Feature depends.

§ SPElementDefinition—Represents a single element that will be provisioned when the Feature is activated.

Accessing Features

We are going to write a windows application to list the Features installed in a site. Create a new Windows Project and add reference to Microsoft.SharePoint.dll.

 
Now let me explain few important lines in the code above. First you need to add 4 windows controls to the form.

Control Type	Control Name
TextBox	siteUrl
Button	Button1
Label	statusLabel
ListView	faetureList

The dbConn contains the connection string to the SharePoint configuration database with credentials. _rootCollection will contains the SharePoint site url which will iterate through the features installed to check whether each feature is enabled or not in the GetFeatureEnabled method. Creating a new instance of the SPFarm class we are connecting to the Database with the given connection string. Then we iterate through the feature definitions which will be added in to the ListView as ListViewItems. Let’s see how it works, hit F5 to run the application.

Features and Feature Definitions

These two are not the same, and it is very important to know the difference. A Feature definition, as far as the object model is concerned, is an abstraction around the Feature manifest contained in a Feature directory in the Features directory. Feature definitions are installed at the farm (or server, if there is no farm) level.

A Feature is an instance of a Feature definition. And it’s features that can be activated or deactivated. Features have various levels of scope such as the site or web level.

To enumerate the list of Feature definitions that are currently installed within a farm, you need to use an instance of the SPFarm class and access the FeatureDefinitions property. To enumerate the list of active Features on a given site, you need to enumerate the Features property on the appropriate SPWeb or SPSite class instance.

As you can see what features are activated and which are not, you can do the activation and deactivation with the code. But it is the GUID that has to be provided.

SharePoint Object Model for Solutions

Other than the command line tool stsadm.exe you still can programmatically manipulate the list of solutions available with in a farm. All you need to do is open a connection to the farm by creating a SPFarm object and fire the Open method passing the database connation string as we did in the earlier example.

Adding a solution you have two options. You can pass the Solution filename as a parameter, or you can pass the Solution filename and a locale identifier (a UInt32, such as 1033):
 
When removing a solution you can pass the solution name or the GUID for the remove method as a parameter. Iterating through the installed solutions in a farm can be done as given below.

Solution Deployment

Deploying solution with object model’s SPSolution class has two interesting methods which are the Deploy and the Retract methods. The Deploy method deploys a Solution to the given location, whereas the Retract method removes the Solution from the given location while still remaining installed within the farm.

Summary

This article included details on how to manipulate Features and Solutions programmatically using the SharePoint object model. If you followed me through the article, you should not only be able to create your own Features and Solutions, but you should also be able to install, manipulate, and deploy them programmatically.

You are welcome to put comments :)