Our Blogs

• Upgrading SharePoint Site Columns

  Mark Jones - Saturday, May 16, 2009

  Introduction

  In a previous post, I explained my findings with "Upgrading Content Types", but now I want to test out a few scenarios with upgrading Site Columns. On the whole, the test results for Site Columns were pretty similar to that of Content Types. Although, I wanted to test what we can do when it comes to updating site columns that contain data. If you don't want to read each test case, please check out the "Summary" at the end of this post.

  Test Cases – Removing a Site Column

  Can we remove a site column by deactivating the Feature that deployed it? Yes

  Test Steps:

  1.       Deploy a Site Column (via Feature and CAML)

  2.       Deactivate the Feature

  Outcome:

  1.       Site Column will be removed

  2.       Feature is deactivated

  Can we remove a site column (thats referenced by a List Column) by deactivating the Feature that deployed it? Yes

  Test Steps:

  1.       Deploy a Site Column (via Feature and CAML)

  2.       Add the Site Column to a List (as a List Column)

  3.       Deactivate the Feature

  4.       Recycle Application Pools

  Outcome:

  1.       Site Column will be removed

  2.       ...

  Full story

  Comments (3)

  Category: SAF

  Tags:: CAML Deployment SAF Best Practices

• Upgrading SharePoint Content Types

  Mark Jones - Saturday, May 16, 2009

  Introduction

  Well it's now Saturday afternoon and the family have been out shopping all day, so I have taken the opportunity to conduct some tests that I had been meaning to do for a long time now (geek I hear you say). I wanted to find specifically what happens if you want to make changes to Content Types, Columns and Lists that have previously been deployed using Features and CAML. I am going to split my findings up into several posts.

  I will detail each set of tests then summarise at the end what I think should be best practice if you want to update these.

  Test Cases – Removing Content Types

  Can we remove a content type by deactivating the Feature that deployed it? Yes

  Test Steps:

  1.       Deploy a Content Type (via Feature and CAML)

  2.       Deactivate the Feature

  Outcome:

  1.       Content type will be removed

  2.       Feature is deactivated

  Can a Content Type can be removed that’s in use by a List? Yes (and No)

  Test Steps:

  1.       Deploy a Content Type  (via Feature and CAML)

  2.       Reference it in a list

  3.       Deactivate the Feature

  Outcome:

  1.       Content Type is removed

  2.       Feature is deactivated

  3.       ...

  Full story

  Comments (4)

  Category: SAF

  Tags:: CAML Deployment Best Practices

• 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

• 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