SharePoint Foundation Development - Part2

Element Types

The below most common element types used when developing feature definitions, along with a brief description of each element type.

Common Element Types Used When Developing a Feature Definition

Element Type	Description
PropertyBag	Adds name-value properties to a feature
ListInstance	Creates a list instance
CustomActionGroup	Creates a new section for links
CustomAction	Creates a new link or menu command
HideCustomAction	Hides a built-in or custom link or menu command
Module	Provisions a file from a template file
Field	Creates a site column
ContentType	Creates a content type
ContentTypeBinding	Adds a content type to a list
ListTemplate	Creates a custom list type
Control	Creates a delegate control
Workflow	Creates a workflow template
WorkflowActions	Creates declarative workflows
WorkflowAssociation	Associates a workflow template with a list
FeatureSiteTemplateAssociation	Staples a second feature to a site template to supportauto-activation

Feature Receivers

Feature receiver used to add event handlers. When the element manifest files can't provide the necessary functionality desired when activating a feature, you can implement one of the four events exposed in the lifetime of a feature.

The events available include:

• FeatureInstalled - Runs after the Feature has been installed
• FeatureActivated - Runs after the Feature has been activated
• FeatureDeactiviating - Runs before the Feature is deactivated
• FeatureUninstalling - Runs before the Feature is uninstalled

Deployment Using Solution Packages

What is a solution package?

• A mechanism for best practice deployment
• Atomic unit of reuse, deployment and versioning
• A set of files and manifest with installation instructions
• A CAB file with *.wsp extension

Solution packages are deployed in two steps.

1. SharePoint Foundation adds a copy of the .wsp file to the configuration database.
2. SharePoint Foundation creates a timer job that is processed by all front-end Web servers in the server farm. 

The manifest .xml file

Each solution package requires a minfest.xml file, mainly serves as instructions to installer on WFE. This file defines the list of features, site definitions, resource files, Web Part files and assemblies to process.

Activation Dependencies

Creates dependency between solution packages. It's newly introduced in SharePoint 2010. An activation dependency blocks the solution from being deployed if the referenced solution has not already been deployed. This is a useful tool when many solutions are dependent upon another solution that should be deployed to the farm such as a shared library or suite of tools.

<ActivationDependencies>

  <ActivationDependency

    SolutionId="0cee8f44-4892-4a01-b8f4-b07aa21e1ef1"

    SolutionName="WingtipUtilities.wsp"

   />

ActivationDependencies>

Creating Solutions with Visual Studio

Solution packages can be created using Visual Studio by creating a simple class library project. The project has to reflect the SharePoint root.

The manifest.xml must be created in the root of the project.

You can use the makecab.exe tool to create the solution package. The makecab.exe tool takes a pointer to a *.ddf( Diamond Definition File) file, which describes the structure of the *.cab file.

Note: The VS 2010 Tools will be discussed later and will automate the process of generating the *.wsp file and making it transparent to the developer.

Farm Solution Deployment

Solution deployment can be done using Windows PowerShell scripts.

• Call Add-SPSolution to install solution package
• Copies *.wsp file to the configuration database
• Call Install-SPSolution to deploy solution package
• Pushes *.wsp file to each WFE and runs installer

Updating a Farm Solution

• Used to push out new files to WFE
• Used to replace images or DLLs with new version
• Used in feature upgrade

When the upgrade or update solution process runs, it overwrites the existing *.wsp in the farm solution store and  then redeploys it to all Web applications it was previously deployed to.

Feature Upgrade

• Used to version feature instances in production 
• New with SharePoint 2010
• How does it work?
• Featuer definition is modified with Upgrade Actions
• New feature definition pushed out using solution update
• New to SharePoint 2010 is the ability to write custom upgrade actions

Upgrade Actions

• Instructions for what to do during feature upgrade
• ApplyElementManifest - used to process element manifest.
• CustomUpgradeAction - used to execute event handler
• AddContentTypeField - used to add new column to existing content type

Triggering Feature Upgrade

Updating solution do not trigger feature upgrade, feature instances must be queried and upgraded. Typically it's done using powershell scripts.

The process of upgrading a Feature is not an automation action. This is something a developer or administrator must perform at the console of the server.

SharePoint Foundation Development - Part1

Fundamentals of the SharePoint Development Platform - 1
This chapter is divided into two parts. The next part will be published in next week. In the first part I would like to cover the following.

• Server-side Object Model
• The Developer Dashboard
• Developing in terms of Features and Solutions
• Feature Upgrade Enhancements

Server-side Object Model

Everything you can configure in the user interface, is represented by an object in the SharePoint object model. The Farm, web applications and site collections you can configure in the Central Administration, is represented by the SPFarm object, the SPWebApplication objects and the SPSite objects.

The sites are represented by SPWeb objects. Each list in the site is of type SPList and each item in the list is of type SPListItem. Some lists are document libraries and they are of type SPDocumentLibrary, which inherits from SPList. Items in a document library consists of object of type SPFile and SPFolder.

•Farm (SPFarm)

–Web Application (SPWebApplication)

•Site Collection (SPSite)

–Site (SPWeb)

»List (SPList)

•Item (SPListItem)

»Document Library (SPDocumentLibrary)

•File (SPFile)

•Folder (SPFolder)

Creating Console Application (Programming with Microsoft.SharePoint.dll)

Using Visual Studio 2010 you can create a console application to work with the SharePoint 2010 object model. When creating the console application, you have to pay attention that the .NET Framework 3.5 is selected and not .NET Framework 4.0

In the project properties you have to change the project platform target to x64 or Any CPU. If you want to work with SharePoint object model, you have to add a reference to the Microsoft.SharePoint.dll which is located in the 14\ISAPI directory.

You can create an SPSite object based on the URL of your SharePoint site. Use the using construct to make sure the Dispose is called to avoid memory leaks. If you don't use the using construct, just make sure you call the Dispose method on the objects of type SPSite and SPWeb when you don't need them anymore.

Sample Solution

SharePoint 2010 The Developer Dashboard

The developer dashboard has been introduced with sharepoint server 2010. It shows diagnostics and performance-related statistics.

For example

• How long did the request take to run?
• What event handlers were fired?
• In what sequence did these event handlers fire?

There is no built-in UI component that allows a user to enable and disable the developer dashboard. However, you can create a simple console application or Windows Powershell script that does the trick.

Note: I will give step by step instructions in the lab.

SharePoint Solutions

A SharePoint (*.WSP) is a Microsoft cabinet file (*.CAB) that contains files to deploy to SharePoint servers. Files that can be deployed include anything that would go in the SharePointRoot (New name introduced in SharePoint 2010) folder.

Solutions deployed to the farm are available across the farm. A new type of solution, the "sandbox solution" allows site collection administrators to deploy custom code solutions to SharePoint.

The SharePoint Root Directory

The SharePoint system directory (/[...]/14/) has been given an official name in SharePoint 2010: the SharePointRoot.

SharePoint Solution File locations 

Path Relative to SharePoint Root Directory	Template File Types
/ISAPI	Web Services (.svc, .ashx, .asmx)
/Resources	Resource files (.resx)
/TEMPLATE/ADMIN	Application pages used exclusively in Central Administration
/TEMPLATE/CONTROLTEMPLATES	ASP.NET User Controls (.ascx)
/TEMPLATE/FEATURES	Feature definition files (.xml)
/TEMPLATE/IMAGES	Images (.gif, .jpg, and .png)
/TEMPLATE/LAYOUTS	Application pages (.aspx)
/TEMPLATE/LAYOUTS/1033/STYLES	CSS Files (.css)
/TEMPLATE/LAYOUTS/ClientBin	Silverlight components (.xap)
/TEMPLATE/SiteTemplates	Site Definition files (onet.xml)
/TEMPLATE/XML	Custom field type definition files (fdltype*.xml)

Note: If you are familiar with MOSS 2007 development, you can find all the above folders in the WSPBuilder solution.

Designing and Implementing Features

• What is a SharePoint Feature?
• Formally known as a "feature definition"
• A unit of diesign and implementation
• A building block for creating SharePoint solutions
• Features can contain elements
• e.g. menu items, links, list types and list instances
• Many other element types possible
• Features can contain event handlers
• implemented using a feature receiver class

At a physical level, a feature definition is implemented with a set of files that are deployed within a dedicated directory created inside the FEATURES directory. More specifically, a feature's directory contains one or more XML-based files that contain Collaborative Application Markup Language (CAML). The only file required for every feature definition is the feature manifest file, which must be named feature.xml and must be placed at the root of the feature's directory

Features can be used to deploy any type of customization

• Web parts
• Application pages
• Event Handlers
• Custom actions
• Site Columns
• Content Types
• Master Pages
• List Definitions and list instances

The feature.xml file

• feture.xml serves as feature manifest file
• Defines attributes for feature definition
• Can reference one or more element manifests
• Can reference a feature receiver

Example

<Feature

  Id="86628958-8768-4421-8921-E23rt5D67C81"

  Title="Course Calendar"

  Description="A sample feature deployed using ADDALA.TRS.SharePoint.wsp"

  Version="1.0.0.0"

  Scope="Web"

  Hidden="FALSE"

  ImageUrl="ADDALA/FeatureIcon.gif"

  xmlns="http://schemas.microsoft.com/sharepoint/" >

  <ElementManifests>

    <ElementManifest Location="elements.xml" />

  ElementManifests>

Feature>

The feature definition file (feature.xml) provides metadata information to SharePoint as well as register the actions the Feature should perform when activated and files related to the Feature.

Element Manifest Files

• Element manifest contain declarative elements
• Listinstance elements creates list during activation
• Many other element types available
• element manifest can contain many elements
• feature.xml file can reference many element manifests

The element manifest files in features is the way you will declarative do work when a feature is activated.

<Elements xmlns=http://schemas.microsoft.com/sharepoint/ >

  <ListInstance

    FeatureId="00BFEA71-7E6D-4186-9BA8-C047AC750105"

    TemplateType="105"

    Id="Courses"

    Title="Coursess"

    Url="Courses"

    OnQuickLaunch="TRUE"        

  />

Elements>

Note: In the second part I will be covering the following.

• Element Types
• Feature Receivers
• Deployment Using Solution Packages
• The manifest.xml file
• Activation Dependencies
• Creating solutions with Visual Studio
• Farm Solution Deployment
• Updating a Farm solution
• Feature Upgrade
• Upgrade Actions
• Triggering Feture Upgrade