SharePoint Config

Before getting into SharePoint 2010 I’d like to recap on some of the things I’ve learnt using SharePoint 2007. Much has progressed since I started working on SharePoint 2007 Technology Adoption Program (TAP) projects using the SharePoint 2007 Beta versions in early 2006. As a developer some of the biggest improvements I’ve noticed are the availability of tools and information.

In 2006 we were creating WSP files by manually maintaining DDF files and using makecab, a process that is now fully automatable (and integrated into Visual Studio) using freely available tools such as the brilliant WSPBuilder utility. I also remember spending two whole days trying to create a list definition as the documentation on MSDN wasn’t (and still isn’t) complete. Not surprisingly the ‘Creating a Custom SharePoint 2007 List Definition’ blog post I wrote afterwards still draws in over 1500 page views a month.

So below are a list of some of the ways I like to do things when creating custom SharePoint 2007 solutions (with a focus on Web Content Management).

Development environment setup

I’m a big fan of Microsoft Hyper-V for development (and even QA/UAT environments). Performance is great and you have the benefits of using checkpoints – a feature I’d now find it hard to live without. I’ve used virtual machines on secondary hard drives before but performance was never amazing. Installing Windows Server on your developer machines is another option but if something goes wrong it can take a while to rebuild.

I also like to create a base image with all the development tools I frequently use. This can then be copied for new developers/projects, renamed/joined to a domain and ready for the (scripted) SharePoint install. Some of the tools I like to include are:

· WSPBuilder – brilliant for packaging WSP and quick deploy of files to the 12 hive/SharePoint root or GAC.

· .Net Reflector – frequently used to work out what is going on inside all those SharePoint assemblies.

· SharePoint Manager – great for exploring your SharePoint farm in detail and finding out what content types are in use or identifying the GUID’s for different objects.

· SharePoint designer (aka SharePoint destroyer) – good for prototyping, especially things like the Data View Web Part and Page Layouts before taking these elements into source control so they can be managed and deployed with the rest of the solution.

· U2U Caml Builder – A handy tool for creating CAML queries.

· zevenseas Search Coder – great for getting search queries right before creating controls that use SharePoint search.

· Firefox and Firebug – My HTML/CSS inspection tool of choice.

· SPDisposeCheck – Tool for checking you are properly disposing of SPSite and SPWeb objects. Read the article Best Practices: Using Disposable Windows SharePoint Services Objects if you haven’t already.

· DebugView – An easy way to inspect standard call to System.Diagnostics.Trace or Debug.

· Fiddler 2 – Good for inspecting network traffic for hunting down network related issues.

For source control I like TFS as it also links in work item tracking/reports/bug tracking functionality but if people are working remotely Subversion is pretty quick across the web.

Other handy tips are to add the SharePoint XML schema files into Visual Studio to give you intellisense, and to disable the Certificate Revocation List check to reduce app pool recycle/Stsadm load times – especially when the development environment doesn’t have internet access. You can also set development SQL databases to simple recovery to reduce disk space (although ideally with a checkpoint to roll back to).

Scripted SharePoint installation

If you are going to be installing SharePoint on more than one environment I’d highly recommend scripting the base installation. The benefits are huge, not only does it drastically reduce the time to build a new server (e.g. multi-server farms can be built from the OS up in 2-3 hours), it ensures that all your environments are in sync and lowers the risk of configuration related issues cropping up late in the deployment cycle. A simple batch script or even better a Powershell script will do most of the work here – simply call psconfig and Stsadm commands for the bulk of the work. To fully automate the process Gary Lapointe’s Stsadm commands for 2007 and his brilliant Powershell scripts for SharePoint 2010 are a great start and it is fairly straightforward to create your own if you have any additional requirements.

Project setup

If you are using WSPBuilder check out the article “SharePoint Developer Productivity Tip #1 – Visual Studio Project Templates” which walks through common setup tasks and provides a Visual Studio template for starting SharePoint projects. I’ve extended this idea and created SharePoint Intranet and Public Website base projects I use to get up and running quickly with new SharePoint projects. These contain the following elements that I can tweak and extend for each solution (all packaged up as features/solution artifacts):

· Site Definition – A base site definition containing relevant features (e.g. publishing infrastructure). I like having a site definition for each site as it means you don’t have to staple features to existing site definitions, and you have more control over the features, lists, properties and default pages for each site.

· Master pages page layouts – A common requirement for almost every project. For intranet projects this looks fairly similar to the OOTB default masterpage but allows for more control over the layout of the page and adding custom controls etc. For public facing sites or other sites that require significant UI changes (e.g. div based layouts) I’ll start from a minimal master page especially if the HTML will be pre-built or a complete change from the OOTB master pages. When creating new page layouts I’ll either create these using SharePoint designer and copy them into Visual Studio or even just create them from scratch in Visual Studio so they are easily deployable. SharePoint designer has its place but I’ve found it doesn’t work well for team based development as it is hard to manage changes and quickly deploy these to other developers or package into a release.

· Site columns, content types and list definitions – custom metadata is required for almost every project so I like to have content types that extend the OOTB content types such as the Welcome Page and/or Article Page so I can easily add custom columns as required. All packaged as a feature for easy deployment.

· User controls – great for adding functionality that you want to bake into a master page or page layout. Common examples are custom navigation elements (e.g. a footer control) or any component where you don’t need the flexibility of a web part but want a design surface.

· Web parts – if you want to be able to allow end users to place a component on a page and/or modify settings then web parts are the way to go. Common requirements here are aggregation web parts such as rollups or related items. I don’t like hard coding HTML/Javascript inside my assemblies so I’ll usually either load an XSL transform or ASCX file which contains the HTML. This makes it far easier to make changes to the output and speeds up development. Additionally in many cases the OOTB web parts suffice (especially the CQWP and/or Summary Links) so I’ll set the properties I want, export them and package them up as a web part specific to the project I’m working on (often with a custom XSLT if the web part supports it). Waldek has some more information on this in his article “Leveraging ASP.NET User Controls in SharePoint development“.

· Server controls – server controls are great for functionality that doesn’t require a design surface. Common scenarios here are things like display panels (e.g. showing different content based on a zone) or things like field controls that aren’t provided by OOTB like the email address of the page owner.

This is only really a start, and big projects will have many other components such as event handlers, field controls and many others that aren’t in the scope of this article. Wherever possible, however, I’ll package everything up using SharePoint features so I can deploy this as one or more WSP’s.

Scripted solution deployment

Deployment is often underestimated by inexperienced SharePoint developers, but can easily cause lost days manually deploying and configuring to try and get a release out. Additionally manual deployment steps increase the risk of inconsistencies between environments which isn’t good for platform hygiene and can lead to expensive delays tracking down deployment related issues. Having scripts to quickly deploy your solution will make it easy to get new developers started, apply changes, saving hours or days in the development cycle.

For SharePoint 2007 I’ve found batch scripts that call Stsadm commands together with Gary Lapointe’s Stsadm extensions do most of the work. You can either extend these or even use the feature framework do automate tasks such as creating content – I often use a feature receiver that reads in an XML file to create pages/web parts/lists etc using the object model. While this can be done using CAML in several cases I’ve found it much faster to create a cut down provisioning feature especially to deploy web parts and make updates to lists etc.

Summary

This isn’t a comprehensive summary of everything you need to consider for a SharePoint project but I hope it provides some helpful tips if you continue to use SharePoint 2007 as a development platform. Comments are especially welcome on this post, I’d love to hear how other people work. Additionally if you would like to hear more on anything please drop me a line or leave a comment below.

Additional resources

Chris O’Brien has some other good tips in his articles “My top 5 WCM tips presentation” and “My favorite SharePoint 2007 development techniques (with an eye on SP2010)”

Waldek Mastykarz has a page containing a bunch of useful SharePoint tools and his blog is well worth a read for other useful SharePoint development techniques

And don’t forget the official documentation on Technet and places such as the SharePoint developer site which has slowly become more and more useful.