SharePoint Site Columns and Site Content Type Customization Best Practices

It’s ever burning question – Should you deploy site columns & site content types using Browser or CAML or .NET Object Model? It feels like every few months or every time I start new custom development project, I ponder on various options available to provision site columns and site content type and I go through similar exercise of putting together quick pros and cons of each approaches. Having done so many times, it doesn’t take long to go through this exercise. But, for once and all, I am going to post my exercise on my blog to avoid similar exercise in future.

There are various options in SharePoint (Same in SharePoint 2007, 2010, and 2013) to provision core components like Site Columns and Site Content Types – Browser, SharePoint Designer, CAML based declarative, and .NET based object model code. This article outlines various pro and cons of each approaches and guidelines to use preferred approach.

Browser Based Custom Development

  • Pro
    • No visual studio dependency
    • Power Users/Non-Developers/Designer can easily provision new content types and site columns
  • Cons
    • Code portability issue across different environments since GUIDs are generated dynamically while adding them directly in browser
    • No Source code version control
    • No control over internal name, may create unexpected internal name when creating columns with spaces. this may create problems while referencing these columns in code or web part properties, there is a work around of this issue of creating site columns without space

Feature Based Custom Development

  • Pros
    • Code portability across multiple environments since GUIDs are referenced in CAML, deployable through SharePoint Feature & Solution Model
    • Site columns names are consistent while accessing them through browser or code
    • Ability to have source version control
    • CAML is easy for code readability in Visual Studio
  • Cons
    • Removes site columns/content types when you deactivate the feature, may not able to modify/add/remove/upgrade site columns or content types if they are used in list
    • No validation of dependency while adding/removing site columns or content types, no way to cleanup provisioned artifacts on deactivation if there are dependency
    • Requires understanding of CAML
    • No intellisense support for CAML but there is designer support in Visual Studio

Object Model-Based Custom Development

  • Pros
    • Code portability across multiple environments since GUIDs are referenced in code, deployable through SharePoint Feature & Solution Model
    • Site columns names are consistent while accessing them through browser or code
    • Ability to have source version control
    • Allows flexibility of creation of components from various entry points other than SharePoint feature receivers e.g. application pages, web parts, or non-SharePoint applications like console apps or web services.
    • Unlike site columns defined using CAML, when this Feature is deactivated, it doesn’t remove the assets when you remove the code (unless it’s been explicitly coded)
    • Full control over when to provision/de-provision assets including validation of dependency
  • Cons
    • Cumbersome for code readability

Here are my general guidelines to provision site columns and site content types.

  • If you don’t have requirements for application life cycle and deploying application across multiple environments, both browser and SharePoint Designer based approach would work fine. This would be ideal for power user customization.
  • Things can be really tricky if you are deploying and managing your custom code components for multiple environments like DEV, Test, Staging, and Production. In this situation,  I would definitely throw away both browser and SharePoint designer based approaches. Only valid options would be CAML based declarative or .NET based custom code approaches.
  • While both CAML and .NET based options have similar benefits. There is a big disadvantage while using CAML declarative approach for future upgrade/maintenance scenario once you go live since site columns/content types would be used in content types or lists and it may pose challenges while retracting or upgrading CAML based code. But, having code redability is great benefit for CAML based approaches for cleaner code. I  personally think CAML/declarative approach would be ideal for initial implementation and first go-live and use .NET based approaches while upgrading/adding/removing site columns & content types for future releases of the application.
  • Features provisioning Site Columns and Site Content Types should be hidden to ensure site collection or site administrators don’t deactivate features from browser interface which would cause removal of site columns and site content types resulting into improper functioning of the application.
  • I would high recommended to follow best practices and work arounds for future upgrade/maintenance of Site columns and site content types from Becky’s article – http://blog.beckybertram.com/Lists/Posts/Post.aspx?ID=18

Hope this helps and save some nightmare while upgrading and maintaining SharePoint custom applications.

Advertisements
This entry was posted in Office 365, SharePoint 2007, SharePoint 2010, SharePoint 2013, SP2007 DEV, SP2010 DEV, SP2010 Online, SP2013 DEV, SP2013 Online. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s