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

• 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