SP2010 – developer skills preparation

So either you went to the SharePoint Conference last week, or you didn’t go but have seen the blog articles/tweets about various pieces of new functionality in SharePoint 2010. But ya can’t get your hands on the bits until late November when the public beta is released – so what’s a poor developer supposed to do? Well, lots it turns out. Most SharePoint developers are going to need to learn some new skills if you want to hit the ground running on your first SharePoint 2010 project – this post highlights some “generic” (by which I mean non-SharePoint!) topics and techniques which will be useful. This list is primarily a list I made for myself so your priorities might be different, but it’s really what I’d want my first SP2010 project team-mates (whoever they may be!) to be looking at now.

Note that technically, all of these skills and techniques listed here are optional – if you prefer to do things the 2007 way, generally all those approaches will still work. However, if you’re interested in taking advantage of new platform features (and you should be), this list is for you.

LINQ

Call me a code monkey, but possibly *the* most exciting developer feature for me in SharePoint 2010 is LINQ. If you haven’t used LINQ before with other data sources (e.g. SQL, XML, objects), it basically provides a consistent, strongly-typed way of dealing with entities in your data. In SharePoint’s case, this means webs, lists and list items, so we have the option of moving away from code like this:

   1: using (SPSite site = new SPSite("http://cob.spfoundation.dev")

   2: {

   3:     using (SPWeb financeWeb = site.OpenWeb("/finance"))

   4:     {

   5:         SPList announcementsList = financeWeb.Lists["Announcements"];

   6:         foreach (SPListItem announcementItem in announcementsList.Items)

   7:         {

   8:             DateTime expires = DateTime.MinValue;

   9:             if (DateTime.TryParse(announcement["Expires"].ToString(), out expires))

  10:             {

  11:                 // we finally got the value..

  12:             }

  13:         }

  14:     }

  15: }

To something like this:

   1: using (FinanceWebDataContext financeWeb = new FinanceWebDataContext("http://cob.spfoundation.dev/finance"))

   2: {

   3:     EntityList<Announcement> announcements = financeWeb.Announcements;

   4:     foreach (Announcement announcement in announcements)

   5:     {

   6:         DateTime expires = announcement.Expires;

   7:     }

   8: }

In effect, LINQ provides your data access abstraction for free. In addition, other data access scenarios such as inserting/updating list items and querying lists (think SPSiteDataQuery or SPQuery) will also be simplified. If you don’t already, my advice would be to start to understand fundamental aspects of how LINQ works (e.g. deferred execution) now.

Recommended reading:

• LINQ homepage
• Basic LINQ query operations
• Introduction to LINQ queries
• LINQ from clause
• Lambda expressions

jQuery

Another innovation in SharePoint 2010 is the client object model, which allows us to work with SharePoint data on the client (e.g. in JavaScript or Silverlight) in much the same way as we’re used to in .Net code on the server. In the case of JavaScript, jQuery will be useful here (though certainly not mandatory) because of the script which will frequently surround your use of the client OM. Put simply, whatever kind of objects you’re using in JavaScript, if you’re interacting with page elements jQuery is likely to reduce and simplify the code required.

Recommended reading (a book I read in this case, though I’m sure great online guides exist too):

• jQuery in Action 

PowerShell 

I’d probably been avoided learning PowerShell to date, partly because there always seemed to be another way to do things which wasn’t too bad. However, it’s clear PowerShell will play a greater role in SharePoint than previously courtesy of the many cmdlets included in the product – certainly admins who are script-inclined are likely to be very happy. The draw here is the sheer power – PowerShell is known for being able call into the .Net framework (and your own custom code), but is also capable of dealing with the filesystem, registry etc. This means that PowerShell can be used for a variety of SharePoint related tasks – scripted installations, configuration scripts, site provisioning/updates and more.

Recommended reading:

• PowerShell homepage
• Official PowerShell blog

Silverlight

Whilst it wouldn’t necessarily have been difficult for skilled developers to build a custom web part to render Silverlight movies, it’s an indication of Microsoft’s desire to make it easy to build rich sites that Silverlight web parts are included in the SharePoint 2010 box. Having had to integrate Flash movies from other teams with XML data sources in the past, having this kind of technology on the “Microsoft developer” side of the fence is pretty appealing. If you have the skills you’ll be able to build web parts with killer user interfaces, and assuming Silverlight is available to your audience the whole SharePoint world will be able to use them.

Recommended reading:

• Official Silverlight site
• Scott Gu’s Silverlight tutorials

FAST search

You’ve probably heard that SharePoint Server 2010 has native integration with FAST search technology. If you’ve seen the capabilities of FAST and/or had conversations with clients about going beyond a ‘standard’ implementation of search, you’ll know how exciting this is. On my last project I worked with some guys from FAST on a proof-of-concept with extremely custom integration between SharePoint/FAST, so it’s great to see the barrier to entry being lowered here. For many, seeing the art of the possible in this space is a real eye-opener – often you don’t realise what you’ve been missing until you see it. On this one, my main recommendation at this stage is solely to introduce yourself to the concepts used by FAST such as the document processing and query pipelines, dictionaries, entity extraction and so on.

Recommended reading:

• Enterprise Search/FAST page on microsoft.com
• FAST search engine for SharePoint PART 1 (Dictionaries)
• FAST search engine for SharePoint PART 2 (Overview of FAST)
• FAST search engine for SharePoint PART 3 (Content Sources and Connectors)

WCF

This one makes my list for two reasons – partly because many of SharePoint’s own web services are now WCF services, but also because if you ever want to build a service application in SharePoint 2010, you’ll need to do WCF work. In general terms, it’s good advice that all new .Net web services should be built using WCF (.svc) rather than as .asmx web services anyway.

Recommended reading:

• WCF homepage
• WCF samples on MSDN 

Summary

The technologies underpinning SharePoint are changing with the advent of SP2010. Now is a great time to prepare for this by spending some time with them outside of a SharePoint context, so that when you do encounter them when used together you're ahead of the game.

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!