As my first SharePoint 2007 WCM project comes an end (for phase 1 that is), I think it is a nice moment to take a step back and post my thoughts on the development process in WSS3 and MOSS 2007.

I’m not going into the details about the project at this stage, in this post I would just like to share lessons learned and my ideas and tips on development.

Before giving my own thoughts, a good article was recently posted on MSDN containing guidelines for team based development on SharePoint 2007: Team-Based Development in Microsoft Office SharePoint Server 2007 (http://msdn2.microsoft.com/en-us/library/bb428899.aspx). I was glad our own approach to SharePoint development was very close to was is recommended, so I won’t go over the same points in this post.

Essential tools and resources
Most of the development helpers and tools I use are already posted in a separate page on this site: see Resources. These are the basic ones every developer in the team had to install:
- Visual Studio 2005 WSS3 Extensions
- The WSS3 SDK
- SharePoint 2007 SDK and the ECM Starter Kit. The starter kit contains some nice code samples.
- Reflector.Net for digging into the SharePoint classes when documentation was well, not very extensive.

I bundled my ideas in a few tips:

Tip 1: Build and test your development by using solutions
During development of custom features, application pages, web parts etc we used batch file based installation files. We used XCOPY for installing custom features, custom pages in the layouts directory, the gacutil.exe for registering and so forth. This works fine at first but as you eventually will need to combine all those developments into a SharePoint solution don’t wait on that. Create the solution from the start so that your installation process gets tested. The nice thing about solutions is that when you uninstall the solution all installed files get nicely deleted/cleaned from all the SharePoint 12 hive directory. No need to manually go through the installation directories and delete custom layout files, features and the like.

Tip 2: put it all in a solution
Why is this second tip as well as the first? Well I can’t emphasize enough how important it is to integrate as much as possible in the solution. You can add SafeControl sections for webparts, custom config sections, features, add CAS sections that are automatically merged into configuration, add root files that should go into the 12 hive root, site definitions that are nicely installed into the different directories (for site definitions, template files go into ‘C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates’; webtemp*.xml files go into ‘C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML’) and so on.

Tip 3: CAS for web application assemblies
If you follow the guideline that is to install your custom DLLs in the web application’s bin directory you will need to use CAS (Code Access Security) to define the permissions your assembly gets when running on SharePoint. Don’t start by installing your assembly in the GAC and then moving to the web application later. You’ll probably just lose time when doing the change. CAS might seem extra work in the beginning but is essential to get your assembly to run correctly when installed in the application’s bin directory.

Tip 4: use features
This might as well been tip # 1, everything can be a feature! Features can be used to create content types, libraries, instantiate lists, add event receivers, customize setting, and so on and so on...
Important during the analysis phase: don’t make too many features either. The analysis phase is crucial to correctly separate or combine customizations into features. I would recommend analyzing the benefits of separating elements into features or combining several elements into a single feature.

Tip 5: For multiple language interfaces, test in every language needed
Test your development and customization in every language early in the development process. My own development setup is in English but at the client we are using a Dutch version. This gave us a few small problems as we hadn’t foreseen because sometimes display names are used to access lists or base SharePoint elements.
Use resource files and satellite assemblies for translated elements.

That’s it for now. I have more ideas on this but will put those in another post when I get the time to present them in an orderly fashion.

So what are your ideas on the WSS and SharePoint development?