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.