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