Quick Refresh on SharePoint Development

A few months back I had a new client who was just testing the water in SharePoint development. They had recently inherited a project based on SharePoint 2007, but were not sure where they needed to start, so as the kind consultant I am, I first made the argument that we should look at an upgrade to 2010, while internally debated this I provided them with the following high level review of developing in a SharePoint environment.

Some of the details are very applicable to both SharePoint 2007 and 2010 development, with major differences called out.

SharePoint Version Naming

The term SharePoint can be used to describe a rather large collection of features, but during installing and development planning it is important to understand the different versions available and their corresponding names.

Windows SharePoint Services 3.0
- Also referenced as WSS 3.0
- This is the basic functionality for a collaboration site, it is free with all Server 2003/2008 licenses and is what MOSS 2007 was built on.

Microsoft Office SharePoint Server 2007
- Also referenced as MOSS 2007
- This is the enterprise instance of the SharePoint framework.

SharePoint Foundations 2010
- Also referenced as SharePoint Foundations
- This is the renamed and upgraded WSS.
- Some users may call refer to this as WSS 4.0 but that is not found in official documentation.
- This is free with most Server 2008 /2008 R2 licenses

SharePoint Server 2010
- This is the enterprise installation.
- The terminology of MOSS 2010 / MOSS has been mostly removed from the jargon, with just MOSS ninety-nine percent of the time always referring to Microsoft Office SharePoint Server 2007.

Throughout the following documentation I have used the term SharePoint 2007 to represent both WSS 3,0 in MOSS 2007 and SharePoint 2010 to refer to both SharePoint Foundations 2010 and SharePoint 2010 for simplicity sake.

The Environments

The following diagram shows the common separation of environments for most SharePoint development. The Team Development is defined in the next section, while your Testing and Production (the second and third boxes below) should be close to perfect clones of each other allowing for perfect testing before live deployment.

Pasted from <http://msdn.microsoft.com/en-us/library/ff650082.aspx>

A properly separated setup allows multiple developers to be working on either the same or different customizations at the same time and an avoidance of naming issues and toe stepping.

Developer’s Box

One of the biggest restraints is that development of custom code for SharePoint must be done in an environment that contains an installation of SharePoint. (For SharePoint 2007 this requires a Server OS installation, while SharePoint 2010 does provide an installation on a Windows 7 Professional OS.) No matter, the targeted version, the recommended approach is to use an all encompassing virtualized machine. This machine would include at the very least:

SQL Server Instance
SQL Management Studio
Targeted SharePoint server
Visual Studio
ULS Viewer
- Write Up: https://thecodeattic.wordpress.com/2010/11/16/uls-the-ugly-log-stream-is-no-more/
- Download: http://archive.msdn.microsoft.com/ULSViewer

WSP Builder
Visual Studio Tools for SharePoint (Required for SharePoint 2007 and Visual Studio 2008 development)
Compression Software such as 7 Zip
- Download: http://7-zip.org/

Source Control software

This all encompassing box can then be cloned and redistributed to new developers as needed or allow for fresh environments to be generated as new task or customizations are assigned. Here are instructions to cloning a SharePoint 2007 development environment http://code-journey.com/2009/clone-sharepoint-moss-wss-stand-alone-developer-virtual-machine-rename-sharepoint-server/. Similar commands should work for a SharePoint 2010 virtual machine.

If there is any external data that the developers will need access to for there own development there is no issue with them sharing a centrally located SQL Server.

Deployment

Once your environments have been established, or at the very least planned out, a big worry becomes how difficult is it to move my customizations between the environments. SharePoint natively has a packaging concept that makes deployment of code between environments straight forward, clean, and simple.

The top level package component is called a SharePoint Solution file, these are identified by an extension of ‘wsp.’ At its basic level a solution is the collection of related files, customizations, and code which are packaged together for easy deployment. A solution is a recommended form of deployment for sets of customizations, because the solution has the capability to be deployed, upgraded, and even retracted.

A solution package ideal should be a collection o f SharePoint Features. A SharePoint Feature is the packaging of a single customization or functionality in a way that can be scoped and activated/deactivated as required by the solution.

Feature

The most basic/smallest package is called a feature. A feature contains a usually one piece of functionality that can be toggled on or off depending on the need. The following diagram shows most items which are packaged within a feature.

When developing a feature, it must be determined at what level within the SharePoint hierarchy the contain functionality can be activated, this is commonly referred to as the feature’s scope. Possible options in tree form are:

Farm
- Web Application
  - Site (Site Collection)
    - Web (web site / sub site)

It is common that a feature activated at a higher level of the hierarchy the functionality will be accessible/working at the lower levels.

Installing Solutions and Features

Features are not reliant on a solution file for deployment to the server, but may require additional manual steps or a more detailed script to be deployed. This is one of the benefits of solution deployment files are properly copied and loaded onto the server natively by SharePoint.

Deployment for either SharePoint 2007 or 2010 can be done via script files or performed via the Central Administrator UI. For reproducibility, it is recommended to perform the deployments with a script file. SharePoint 2007 relies on the command line command STSADM (found in the bin directory of the 12 hive., while SharePoint 2010 has been designed to leverage the power of PowerShell (the STSADM is there but no longer the recommended scripting language.)

SharePoint 2007 Deployment Commands
Solution Deployment

stsadm –o addsolution
stsadm –o deploysolution
stsadm –o execadmsvcjobs

Feature Installation and Activation

Stsadm -o installfeature

This does not need to be ran if the feature was part of a solution. The solution handles feature installation.

Stsadm -o activatefeature

Depending on the solution this may or may not need to be ran.

SharePoint Object Model Hierarchy

When writing custom code for SharePoint 2007 and SharePoint 2010 there is a specific hierarchy to common objects required to interact with your SharePoint data. The following image is taken from a presentation by Lynn Langit called "SharePoint Development with Microsoft Visual Studio 2010" and can be found at http://blogs.msdn.com/b/socaldevgal/archive/2010/08/09/sharepoint-2010-for-net-developers.aspx. I thought this graphic is the simplest and easiest way to see how the major SharePoint objects are nested within each other.