To Dispose or Not To Dispose? Here is the question.

One of the best articles that I’ve read so far about the importance of properly disposing SPWeb and SPSite objects has been written by one of my favourite SharePoint bloggers Stefan Gossner and can be found here.

Unfortunately there are still some conflicting messages about what to do with SPWeb instances creates via the SPSite.RootWeb property. According to Stefan we need to call dispose but other people from Microsoft are saying the opposite as you can see here.

So the search continues….

SharePoint Lessons Learned – Clearly Define a Deployment Baseline (Part 2)

In part 1 of this post I’ve talked about the principles behind the creation of a Deployment Baseline during the development of SharePoint based applications. In this post I’m going to talk about how we, at Collaboris. normally group and categorise the different artefacts to create this baseline.

This post assumes that you are familiar with the concepts of SharePoint Features, Site Definitions and Solution Packages. For a primer on these concepts please refer to this page on MSDN.

There has always been a lot of debate around the best way to deploy SharePoint applications. Some people do not like Site Definitions or Features and prefer to use Site Templates (.stp), others prefer xcopy deployment and others like me stick with Features and Site Definitions deployed using Solution Packages. I’m not going into that debate here, I’m simply going to describe the approach that we have been taking for the last few years without any regrets.

Like I’ve mentioned on the first post I’m strong believer in using the SharePoint Features and Solution Framework for the delivery of SharePoint applications. We normally try to deploy most of the artefacts via Features which are activated via Site Definitions and deployed using Solution Packages (WSP). One of the biggest advantages of using WSPs as a delivery mechanism is that SharePoint will automatically deploy the WSP contents to all Web Front End servers on the Farm.

We normally try to identify the deployment artefacts very early in the development lifecycle. Normally just after the initial requirements analysis. We use Mind Maps during this stage because they are very easy to produce and can quickly give you an high level overview of what needs to be delivered. We call these documents “Deployment Artefacts Maps” and we normally create two; one showing all the sites, pages, doc libraries and lists (see example below) and another with all the UI controls. These are dynamic documents that will evolve during the project lifecycle.

 

Example of a Deployment Artefact Map

 

These “Artefact Maps” together with a high level domain model (that helps me to understand the complexity of the data) allows us to size and cost the project from very early stages.

The next step is to group the artefacts and define a deployment strategy for each group. We normally organise them into into three major groups:

1. Infrastructure Artefacts (CSS, Style Images, Page Layouts, Site Columns, Master Pages, Content Types, List Templates, etc) – normally deployed via Features and CAML scripts and activated via Site Definitions (so that they are automatically activated when a site is created).
2. Configuration Artefacts ( Permissions, Navigation, Search Scopes etc) – deployed via features but using a mixture of CAML and custom code called from feature receivers to overcome some of the CAML limitations. This is were tools like SAF are most useful and can dramatically decrease the amount of effort require to deploy your application (SAF is a fully extendable XML framework that incorporates a series of custom actions that extend the functionality provided by CAML. For more information on SAF please follow this link ).
3. Content Artefacts (documents, page layout content, content images, lists content etc) – we normally subdivide this into 4 subcategories:

• Static Content – This is content that it will not change and you want to be there from day one (when the site is first deployed). We normally use a feature with CAML to deploy this.
• Sample Content – It’s a lot easier for business users to be given a site with some sample content that exemplifies how the site can be used. This content is deployed via a feature that can be manually activated by a site administrator.
• Test Content – normally created by the test team to cover all the different test scenarios. This content is created once and then manually activated by the test team (simply by activating a feature) in every test iteration.
• Dynamic/Business content – This is content normally created by business users (sometimes even when the site is still under development). We deploy this content using a SAF deployment action that uses the CMP API to provision the content. One very important thing here is that our feature will only provision content (list items or documents) into an already existing lists that has been created by an infrastructure feature (see point ‘1’ above). This way we clearly keep a separation between infrastructure (the list template and instance) and content. This separation also helps delimiting the areas of responsibility between IT and the Business (IT department is responsible for infrastructure artefacts and business is responsible for content artefacts ).

This was a very high level overview of how in Collaboris we define a Deployment Baseline. The next step will be the creation of a Visual Studio solution to implement the deployment packages defined in this Baseline. But more on that on a future post.

SharePoint Lessons Learned – Clearly Define a Deployment Baseline (Part 1)

One of the major lessons that I’ve learned so far with SharePoint development is how important it is to clearly define your Deployment Baseline from very early stages in the development lifecycle. In part 1 of this blog post I will describe the concepts behind this Deployment Baseline and in part 2 I will describe how in Collaboris we apply them to the development of SharePoint applications.

A deployment baseline is a clear definition of the artefacts that are going to be built and deployed when creating a new application. These artefacts should be catalogued and grouped based on their purpose, functionality and on how we plan to deploy and maintain them once the application is live. This baseline will also help to clearly define the different areas of responsibility within the team.

Imagine that you are developing a new Web Content Managed application where the development team is responsible for the creation of all the technical artefacts (ASP, HTML, CSS etc) and the business team is responsible for the creation of content (pages and documents). In this scenario it will make sense to create two separate packages; one for the technical artefacts the other for the content artefacts. These packages can then be maintained, managed and version controlled separately. To do a release you would just need to release the package with the technical artefacts followed by the content package (you can also have more than one content package but more on that later).

In SharePoint development, the Features and Solution Framework gives you the right tools to define and create this Deployment Baseline and I think that it is a worthy investment to get familiar with it before starting to develop any SharePoint application (strongly recommend Andrew Connell’s book to learn this). Unfortunately this framework also has a lot of limitations that are not immediately obvious when you start to use it so be prepared to get your hands dirty and do some coding to overcome some of them (or have a look at SAF the free tool that Collaboris released on CodePlex).

In part 2 of this post I will go through the steps on how in Collaboris we organise our deployment artefacts to create a deployment baseline for our projects. Stay tuned.

SharePoint Lessons Learned – Don’t forget to use proven design patterns and practices

SharePoint should be seen as another layer in the technology stack that your code will interact with. But just because you are using this layer you should not forget to follow good and proven design practices. The following points describe some of the principles that sometimes seem to be forgotten when using SharePoint:

1. Create a data access layer to access your lists.

   After all you would be doing this if you were programming against a database table so why not do the same for a SharePoint list. The last thing you want is to have several components of your application accessing the same list in several different ways. If the list schema, name or location changes then you would need to change the code in every component that uses that list (this could be acceptable for small proof of concept applications but not for enterprise applications). In a future post I'll be giving an example of designing and coding a simple SharePoint data access layer.

2. Use SharePoint lists to store configuration data. Create a configuration site, on your site collection, containing all the configuration lists

   Before SharePoint all configuration needed by you applications resided in a data store (normally a database). You then needed to build a UI to allow power users and/or administrators to change that information. You also had to implement security mechanisms to make sure that only the users with the correct permissions were allowed to change or access that data. With SharePoint you can accomplish all of that with out of the box functionality without writing a single line of code.

   You can also adopt the same principle for structured content. For example let's say that you want to create a very simple top navigation menu (like the one on the top right corner of this page) and allow your users to add new links or edit existing ones. You could create a TopNavs list on a "/config" site under your site collection with "Name" and "URL" columns. You could then create the menu using a simple ASP custom control and bind it to the TopNavs list. I'll be showing how to do exactly that in a future post.

3. Do not forget about databases

   Just because you are using SharePoint and have all of those nice lists that you can easily create and configure it doesn't mean that you should stop using databases (disregarding the fact that SharePoint is actually storing all of the list data on a database). You should always ask yourself the reasons why you should use a SharePoint list instead of a database table. Remember - SharePoint is a service layer - so if you are not using the services provided by that layer then perhaps you should be using a database table instead. SharePoint lists also have greater limitations than database tables (see this Microsoft document for more information on those limitations).

4. Plan the deployment process early and be very careful with tools like SharePoint Designer

   Don’t assume, that just because you can use the server that sits under your desk to develop fantastic and feature rich SharePoint sites using SharePoint Designer, that you will be able to easily transform them into enterprise class applications that will run on your corporate servers. Sites developed using SharePoint designer are normally difficult to move between environments (development, test and production) and can bypass all the version control mechanisms your organisation already has in place to develop other types of applications (ex. TFS or VSS). So get familiar with the SharePoint Designer limitations before start using it (don’t make everything into a nail just because you have a new shinny hammer).