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:

  • WSP Builder
  • Visual Studio Tools for SharePoint (Required for SharePoint 2007 and Visual Studio 2008 development)
  • Compression Software such as 7 Zip
  • 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.


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.


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.


Help Links for Reference on SharePoint 2007 Development

Helpful Links for Reference on SharePoint 2010 Development


SharePoint Modal Dialogs

SharePoint 2010 finally provided a way out of the horrible page refresh and post backs of SharePoint 2007 when it comes to viewing, editing, and adding items to libraries and list in the form of wonderful JavaScript modal dialogs.

What is even more awesome is that the even provided a way to make it optional for us. Why would would you want to provide full page navigation to these forms? The most common reason is if you have a complex custom form with a lot of fields or data, the full screen version provides benefit to the user, in limiting the amount of required scrolling they may need to do. Also, a concern is for accessibility issues where a screen reader may not detect the modal causing your user to miss out on there details they were hoping to consume.

Turn Off From GUI
To turn off the Modal Dialog from the GUI, the web browser is simple enough.

  1. Navigate to the list. From the List Tools of the Ribbon click List –> List Settings.
  2. This will bring up the List Settings page. From here under General Settings  click Advanced settings.
  3. You will then see the Advance Settings screen. Scroll to the bottom and you will find a row titled "Dialogs" with a radio buttons for Yes and No.
    As the description describes this turns the modal dialogs on and off.
    Yes being display as modals, and No being display as a page.
  4. Click OK and the setting will take effect. Simple once you know where to look.

Turn Off via Object Model
Sometimes there is a need to set the Dialog value via code in the object model. There does exist a property on an SPList object called "NavigateForFormsPages" which controls this setting. As with many other SharePoint object properties the name does not always describe the related purpose.

"NavigateForFormsPages" is a boolean value where
True causes the forms to render as a full page, post back and all. While False, indicates that form rendering should be in the modal dialog. As with any list property settings don’t forget to call SPList.Update() after setting the value.

Here is some sample code of how to set the NavigateForFormsPages value from a Web scoped feature receiver:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
    using (SPWeb web = (SPWeb)properties.Feature.Parent)
        web.AllowUnsafeUpdates = true;
        SPList newList = web.Lists["CourseDirectory"];
        if (newList != null)
            //True - full page rendering
            //False - modal dialog rendering.
            newList.NavigateForFormsPages = true; 

See http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splist.navigateforformspages.aspx on MSDN for the super technical details regarding this list property.

Modal Dialogs and Custom Forms

You’ve written a super sweet custom application page for your content type, and am ready to set it free in your environment. Turns out during the stage testing (you do have a stage server right?) you custom form doesn’t actually close the modal dialog it resides in. Instead the modal dialog opens the redirect link in the current dialog. Possibly your close event code looks something like the following:

protected void btnExit_OnClick(object sender, EventArgs e)
    if (Request.QueryString["Source"] != null)
        Response.Redirect(Request.QueryString["Source"], true);
        Response.Redirect(SPContext.Current.List.DefaultViewUrl, true);

You might see the following strange behavior where you modal never actually closes.

First, we open our item in the custom form, and see


After clicking CLOSE button which has the above custom code we get this:


Since our current context is still the frame set of the modal dialog our supposed closing just loads the code into the current window frame. Luckily,  with a little code and checking the current HTTP context we can close the modal or redirect if modal is turned off. Our new close event code would be this:

protected void btnExit_OnClick(object sender, EventArgs e)
    HttpContext context = HttpContext.Current;
    if (HttpContext.Current.Request.QueryString["IsDlg"] != null)
        context.Response.Write("<script type=text/javascript>     window.frameElement.commitPopup();</script>");
    else if (Request.QueryString["Source"] != null)
        Response.Redirect(Request.QueryString["Source"], true);
        Response.Redirect(SPContext.Current.List.DefaultViewUrl, true);

Now, the following will happen:


And after close, a view of the All Items page of our list:


Now you have the know how to take advantage of the new modal dialog feature of SharePoint 2010.

Recommit to fill the void

I’ve been out of the blogging loop for a year now, and feel it is time to recommit to populate all the free space Word Press provides me. Hopefully you, the reader will find something helpful and interesting from the articles I will be posting.

As part of this goal to fill the free space given out, I am hopeful that the process of writing articles will allow me to become more concise and clear in my ability to provide technical details in a simple, fresh manner making me a better consultant, team player, and developer.

The one thing I took from my first year of blogging is that writing articles requires a more intimate understand of the code and the technology supporting the code which can I then translate into simple yet powerful tidbits of insight for everyone else.

So here we go 2012…more simple and powerful article to help the everyday coder and myself.

Let the void filling begin….Scott