Our Blogs

• SAF is released!

  Mark Jones - Wednesday, June 17, 2009

  At Last! Finally, we have released the SharePoint Action Framework (SAF) on CodePlex!! Please take a look at : http://saf.codeplex.com .

  Now that I can take a minute, I just wanted to spend a bit of time detailing why we have spent the best part of 18 months (with lots of late nights building it!) Here's a FAQ to give you some answers:

  If you are developing with SharePoint, do you suffer from any of these ?

  • Lots of Defects caused by differences in SharePoint Farms. – eg. “It works on Integration, but not on QA!” .
  • Your Development team find it time consuming telling your Release team what to do for each release. “How hard can it be to put 5 columns in a Content Type?”
  • You have release documents (notepad, word, etc) that don’t contain enough information on how to deploy, or they always miss things and are extremely time consuming to create. “By heck surely there must be a better way of telling the Operations team what I need doing ?”
  • Deployments to key farms are always late and very stressful. “I hope we don’t get a release like that again, I didn’t finish till ...

  Full story

  Comments (0)

  Category: SAF

  Tags:: SAF SharePoint

• SharePoint Best Practice Resources

  Mark Jones - Thursday, May 07, 2009

  SharePoint Guidance

  The Patterns and Practices team at Microsoft have developed guidance to help developers and architects build applications on top of SharePoint. The first release covered building intranet applications in a team environment. Release 2 targets enterprise class content oriented applications accessing LOB system information.

  SharePoint Guidance on CodePlex

  10 Best Practices For Building SharePoint Solutions

  An excellent article covering topics such as App Dev, Testing and Continuous Integration.

  Best Practices: Common Coding Issues When Using the SharePoint Object Model

  "Learn common issues encountered by developers who write custom code by using the SharePoint object model"

  http://msdn.microsoft.com/en-us/library/bb687949.aspx

  Best Practices: Using Disposable Windows SharePoint Services Objects

  "Learn best practices to follow when using Windows SharePoint Services objects to avoid retaining the objects in memory in the Microsoft .NET Framework"

  http://msdn.microsoft.com/en-us/library/aa973248.aspx

  Summary of sessions for the European Best Practices SharePoint Conference 2009

  Syed Adnan Ahmed Kindly summarises what he discovered at the European Best Practices SharePoint Conference. He breaks the points down by Web Part Development, Custom Field Types and SQL Server Tuning.

  http://www.codeproject.com/Articles/36209/Summary-of-sessions-of-European-Best-Practices-SharePoint-Conference-2009.aspx

  Developer Best Practices Resource Center for SharePoint Server 2007

  Find up-to-date guidance about how to write Microsoft Office SharePoint Server 2007 applications and customizations that perform well, avoid common pitfalls, ...

  Full story

  Comments (0)

  Category: SharePoint

  Tags:: Best Practices SharePoint

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

  Hugo Esperanca - Tuesday, April 28, 2009

  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 ...

  Full story

  Comments (0)

  Category:

  Tags:: Deployment SAF Best Practices SharePoint

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

  Hugo Esperanca - Sunday, April 26, 2009

  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 ...

  Full story

  Comments (0)

  Category:

  Tags:: Deployment Best Practices SharePoint

• The SharePoint Deployment Maturity Model

  Hugo Esperanca - Sunday, April 26, 2009

  MOSS has been the most successful server product Microsoft ever released. Sales are growing much faster than Microsoft ever expected and apparently the UK is outstripping worldwide growth (for more see this). Unfortunately this quick growth is also highlighting one of the major problems that everyone seems to be struggling with - deployment. I've been working with MOSS since Beta 2 and I have debated this issue with other colleagues and we are all in agreement: deployment is one of the biggest pains on any SharePoint project. It's one of the areas that will give you more problems and cost you more money. What is curious is that all companies adopting SharePoint seem to go through the same evolution path. Finding a way to measure where my customers are on this path gives me a good idea on the challenges that I will be facing when moving their projects forward. The kind of measure that I'm talking about it's called a Maturity Model so I called it the Deployment SharePoint Maturity Model (SDMM). 

  Like the Capability Maturity Model (CMM) I divided the SDMM is divided into 5 levels (except for level 4, I have used the same names ...

  Full story

  Comments (0)

  Category:

  Tags:: Deployment SharePoint

• How to free your Data View/Form web part (DVWP/DFWP) from those nasty GUIDs

  Hugo Esperanca - Sunday, July 20, 2008

  Ever wanted to use the same page layout containing a DFWP, and bind it to a local site list in each site of your site collection ?

  Ever want to be able to deploy a page with a DFWP to a different server?

  If you ever tried any of the above using SharePoint Designer you would have found problems because, by default, SharePoint Designer binds the control to the list instance using the list instance GUID. To resolve this we need to replace the GUIDs by the list name. The steps to do this are:

  1. On the attributes of the DataFormWebPart element replace the attribute ListName="{GUID}" by ListName="LIST_NAME" where LIST_NAME is the name of the list that you are binding to.
  2. Go through all of the DataFormParameter elements and replace:
     
     

     <WebPartPages:DataFormParameter  Name="ListID"  ParameterKey="ListID"  
      PropertyName="ParameterValues"  DefaultValue="{GUID}"/>

     
     with:
     

     <WebPartPages:DataFormParameter  Name="ListName"  ParameterKey="ListName"
      PropertyName="ParameterValues"  DefaultValue="LIST_NAME"/>

  3. Go to the ParameterBindings element and replace
     
     

     <ParameterBinding  Name="ListID"  Location="None"  DefaultValue="{GUID}"/>

     
     

     with:

     <ParameterBinding  Name="ListName"  Location="None"  DefaultValue="LIST_NAME"/>

  This should give you a GUID free DFWP that can be placed on a page layout used by multiple ...

  Full story

  Comments (2)

  Category:

  Tags:: SharePoint

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

  Hugo Esperanca - Friday, August 24, 2007

  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 ...

  Full story

  Comments (0)

  Category:

  Tags:: Deployment Best Practices SharePoint