Wednesday 7 October 2009

My favorite SharePoint 2007 development techniques (with an eye on SP2010)

As we home in on the release of SharePoint 2010, I wanted to write down a couple of thoughts for posterity on SharePoint 2007 development, mainly for my benefit. One of the reasons for doing this is because I’ve been working with the SP2010/VS2010 Tech Previews recently, and whilst I’ve not done a full “compare and contrast” exercise, I can certainly see that in the future I will want to reference back to how I liked to handle something in the SharePoint 2007 world, and more importantly, why. My experience is that transitioning to a new platform brings on a certain amnesia, where for some reason it’s difficult to remember just how the equivalent thing worked in the last version (CMS2002 anyone?) – undoubtedly we need to avoid restricting our thinking with irrelevant practices and constraints, but sometimes the old way is definitely useful as a reference point.

This isn’t a comprehensive list - many of my points below came out of a “developer sunset review” of my last project (special thanks to ex team-mate Jaap Vossers for some of the ideas/discussions we had around this stuff). Some techniques are in there because we used them and they worked great, others because we didn’t and I thought we suffered from not having them. A couple of others are just “things I’ve still not implemented but think would be the best option” – some of which could still be appropriate under SP2010. Many are what I believe to be the established “baseline approach” by many teams implementing SharePoint 2007 – it’s perhaps stretching it to say “best practice” for some, so I won’t. Even so, I’m *sure* so folks will have different views/techniques, these are the ones I wanted to capture – by all means leave a comment or point me to something else if you have better thoughts:

Visual Studio solution/project structure

  • Every VS project which deploys to the 12 folder contains a 12 folder structure 
  • Use the “class library” project template to start with a clean base – edit the .csproj file to add back menu options for ‘Add user control’ 
  • WSPBuilder as WSP-generation tool of choice
  • One main ‘consolidation’ project which is used to generate a single .wsp (where appropriate) – usually this is my [Company].[Client].Project.Web project
  • Use post-build command on each project to XCOPY 12 hive files into the consolidation project, so that avoid having one .wsp for each VS project – fewer .wsps are preferred to reduce versioning/dependency issues
  • User controls – for publishing sites, consider implementing HTML markup in user controls, not page layouts (as discussed in my Top 5 WCM tips post and by Waldek in Leveraging ASP.NET User Controls in SharePoint development)
  • User controls (if not using the above technique) - to get design surface, consider using a separate web project for initial development of user controls, then either using post-build events to copy the .ascx to your main project or using the ‘Add as link’ technique. (As far as I remember this is the only way to have a functioning design surface for user controls?)
    • Remember that many .ascx artifacts cannot exist in a subfolder of CONTROLTEMPLATES (e.g. custom field controls), they must be at the root for SharePoint to load them
  • Use Visual Studio post-build events to re-GAC assemblies and copy 12 folder - so that default action on compile is the “quick deploy” option. This happens so often in dev that I’d rather have any other option require an explicit action on my part, we since rarely want to compile but NOT load new assemblies
  • Consider creating custom VS build types e.g. “DebugNoDeploy”, “ReleaseNoDeploy”
    • Additionally, create a build type to re-provision your site in dev (if this step happens frequently in development of your implementation)
  • Leverage custom VS tool options where appropriate (e.g. “Tools > MyScript.bat”)
  • Re-bin is much faster than re-GAC (for code which can be tested outside of the GAC) – custom tool script or custom build type. This is useful for the highly-iterative part of development.

SharePoint coding tidbits

A selection of random thoughts I want to hold on to, as I think they’ll likely be relevant in the 2010 world:

  • The impact of app pool resets in dev should always be minimized by disabling the Certificate Revocation List check – I notice significant gains when doing this
  • Think carefully before storing data in SPWeb property bags – data stored here is not accessible to a query!
  • Use constants for SharePoint names, in particular field names
    • This is critical for consistency across project teams, and for providing name changes via Visual Studio refactoring
    • On balance, better to have separate DisplayName & InternalName constants
  • Storing configuration values - my Config Store solution has worked well for this
  • Logging – My preferred logging framework is the excellent log4net
    • If you have a requirement to log to a SharePoint list, creation of a custom log4net appender is the way to go. I haven’t done this yet, and bizarrely it seems no-one else has (publicly). Would be fairly trivial to do though
    • Fellow MVP Dave Mann pointed out to me that log4net causes problems when used in SharePoint workflows, as the logger class cannot be serialized when the workflow sleeps. It might be possible to mitigate this by not storing the logger as a private variable, but instantiating every time used (likely log4net returns same object, but performance unlikely to be critical in a workflow anyway)
  • Managing web.config modifications in dev (when you just don’t have time to SPWebConfigModification yet):
    • I don’t have a good story here – the best I’ve come up with is to have a ‘reference’ web.config stored in source control which can be used to sync changes between devs. As a sidenote, perhaps this issue can be avoided if the first coding week on the project lays down the plumbing code for SPWebConfigModification Feature Receivers as a “mandatory setup task”, so that it’s minimal friction when a new web.config change is required – otherwise I think it’s common to skip this and go into “technical debt” until such a time when the team can catch up on such things. And we all know what can happen there..

So whether you start to look at SharePoint 2010 immediately or your day job remains focused on 2007 for another year, I hope this list has been useful. Speaking personally, I know that in the interests of Kaizen (continual improvement), it will be illuminating to look back and see what’s still relevant and what isn’t. Looking forward, like many other MVPs this blog will now focus more on SP2010 going forward – I’ll most likely revisit some of this in view of my experiences with the VS2o1o Tools for SharePoint in the next couple of weeks (after the NDA is lifted). Stay tuned!


Nadège DEROUSSEN said...


Your post is very interesting.
I'd just have a question. Is there a special reason not using VSeWSS in order to package and deploy your solution/feature ? Do you meet some problems with VSeWSS that decide you not to use it and use WSPBuilder instead ?

Thanks for your post and your response.

Einar Otto Stangvik said...

You should add that recycling application pools, rather than pulling a brute force iisreset, significantly improves redeployment times as well :)

Recycling is simple, using WSPBuilder's Visual Studio addin; Harbar's tray util (; or a console app of mine ( (includes source)).

Muhimbi said...

Good stuff Chris. I had a chat with Jaap yesterday and he mentioned your posting. I am seeing quite a few people linking through to our CRL article, so thanks for the 'Link love'

Your list, to some degree, matches what is in our SharePoint development Guidelines (Free download at I hope we don't need to overhaul too much of this when SP2010 is out.

Chris O'Brien said...


Personally I prefer the 'one-to-one' mapping to the 12 folder that having WSPBuilder and a '12' structure in my VS project gives. In early releases (than 1.3 CTP), VSeWSS was far less flexible in some circumstances leading to criticisms it was too much of a 'black box'. I think some of this has been remedied, and it certainly does some things very well - but the other reason I prefer WSPBuilder is because it seems to be the most popular SharePoint dev tool - see Todd's unscientific survey at I like consistency from project to project, team to team, so ubiquity is certainly in WSPBuilder's favour.



Chris O'Brien said...


Good point - I might have omitted this because it's just such a fundamental thing, but only the other day I came across a developer who was doing an IISReset each time.

I've also long used Spence's utility and WSPBuilder to do the job.



Chris O'Brien said...


Yep, the CRL trick deserves to be widely linked :)

I haven't seen anyone publicly publish their SharePoint dev guidelines before, commendable move. Where I worked for a long time, we moved away from writing our own guidelines (for .Net at least) in favour of the IDesign guidelines, but with all the SharePoint specifics I've gone back to thinking it's better to have a single location to point developers to. The SPDevWiki does a good job, but obviously doesn't contain any policies relevant to your organization.

I'll take a read!



Muhimbi said...

Top, it has been out there for a while and some sections require updating.

Regardless, if you have any specific remarks then leave them in the comments in the relevant post or drop me a line.

Thanks for pointing me towards IDesign, they have a WCF naming standards doc that is quite relevant to me at the moment.

Anonymous said...

"If you have a requirement to log to a SharePoint list, creation of a custom log4net appender is the way to go. I haven’t done this yet, and bizarrely it seems no-one else has (publicly)."

Chris, I've done this. It IS in fact quite simple. My appender writes to the SharePoint Trace Log.

If people are interested, contact me: or


Bil Simser said...

@Chris: I totally go with the WSPBuilder way (using both the command line but specifically the VS plugin to start projects). It packages things up great, with the latest release you can put your own .config file in the root and control the output, etc. I use command line version for more complicated builds where I have 3 or 4 wsps then it's NANt and wspbuilder.exe. VSeWSS is just too unworkable IMHO. I may try to give it a chance in 2010 as what I've seen looks better, but it's still behind WSPBuilder (although it does have a few key features like reverse engineering a WSP/STP/site).

Chris O'Brien said...


Yeah the tools in VS2010 are definitely better (note it's not badged as VSeWSS though as it's a completely different model/codebase). Be interesting to see how things play out with large scale 2010 dev though. Also interesting point about running from the command-line - I think this is possible by running dev.exe (VS2010) from the command-line and passing some switches.