Site Features vs Site Templates vs Site Definitions


Table of Contents


Add to Technorati Favorites



Recently Updated

There is a lot of debate around what is the best approach to provision a Site Collection in an environment.

The three techniques listed below show the pros and cons of these. Each technique gives the ability to automatically provision various elements in a Site Collection which gives:

  • Configuration Management control - each environment will be built the same based on the defined scripts
  • Encourages Change Control Management - can control releases via scripts
  • Time to Production - once the scripts are written, can be released in multiple environments by administrators with little effort. A lot more efficient than manual deployment steps which have to be repeated each time
  • Build Server - with the ability to release to an environment, automated testing scripts can be run on provisioned environment

Site Features

Pro
Con
Leverages Feature framework Requires knowledge various programming technologies e.g. C#/VB.NET
Strong site upgrade path (how you upgrade from WSS to MOSS) Requires knowledge of SharePoint Object Model and schemas (and XML)

Site Templates

Pro
Con
Working in UI and SharePoint Designer Reliant on UI to create base .stp as hard to create from scratch
  Doesn't support Publishing Features
  No Feature Stapling
  Doesn't package all settings (Content Type visibility)

Site Definitions

Pro
Con
Great for provisioning Poor upgrade path ( Can't change site def to another one once created)
  Havoc if OOTB defs edited
  Workarounds required for particular things (Devs out there editing stored procs and adding triggers!)
  Requires knowledge of the Site Definition schema and XML

Alternative to Site Definitions

  • SharePoint Site Configurator Feature on CodePlex

    SharePoint Site Configurator Feature is a small framework for taking care of all configurations, settings and featurestapling you need for transforming a standard blank site definition into your own full blown site, without the hassle of creating a complex custom site definition.

An alternative to using a straight site definition is to combine the site features method with the site definitions method. This involves creating a minimal site definition and putting all the functionality that is required into features. Then tell your site definition configurations what features each should use. This way you still have the benefits around the easy provisioning of your site, but have the flexibility to turn on and off features to add/remove functionality from a site definition. Also it then becomes easy to identify sites that were based on specific definitions, allowing for an easy way to find these sepcific sites to add/remove features from them at a later date.

NOTE: It is very important that you don't change the list or order of the features listed in the custom site definition. If you do, you will break all the sites that depend on that definition. As an alternative, you can use a "feature queuer". This is simply a feature that uses a feature receiver to activate other features. As far the site definition is concerned, you have not modified the list of features and thus will not break your existing sites. But you can modify the list of activations in the "feature queuer" for any new sites that would be created from that site definition. It's kind of a workaround changing the provisioning behavior of the original site definition. You can read more about it here Extending Site Definitions with Web Features

An example of how this method could be used is with a customised publishing portal. It has a site definition that contains 4 configurations (1 for the root site, and 3 different sub site models that could represent the different areas of a business and their specific requirements for example) and each use a combination of features to build thier functionality up what goes in to each site. Some of the features that each site uses can be shared (for example, a customised document library might be required in all 3 sub sites, but this is still done with a single feature) while there might be some features that are used in only a specific sub site. After the site is deployed and has been in production for a while you might find you need to upgrade the sites for one of the business areas to add or remove a feature. The site definition can be upgraded and deployed with a new WSP to ensure new sub sites meet the new design, and existing sites can be updated programatically to have the features modified. These sites can be easily identified (through the SPWeb.WebTemplate property) to ensure that only they are upgraded and the other sites are left alone.

So the pros and cons of this variation of the site definitions method are:

Pro Con
Great for provisioning Workarounds required for particular things (Devs out there editing stored procs and adding triggers!)
Sites can be easily identified to upgrade later Can't change a site definition once created (although features can still be enabled/disabled)
Leaverages feature framework  
OOTB Site Definitions are left alone  

External References

Labels

onet onet Delete
sitedefinitions sitedefinitions Delete
sitetemplates sitetemplates Delete
features features Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (12)

 

  1. Dec 17, 2008

    Donovan Regel says:

    Ok. So now I'm a believer in "Site Features" and solution packages. And I go to ...

    Ok. So now I'm a believer in "Site Features" and solution packages. And I go to Codeplex and download and try STSDEV and WSPBuilder and start attempting all manner of things via Features...

    But what I need is more answers on is deploying custom ASP.Net 2.0 webparts as part of a Feature (which I will be stapling to a minimalist blank site definition - following AC's guidance). There is stuff out there on feature stapling, but not a whole lot on deploying custom webparts as part of features. My questions on the topic include the following:

    • There seems to be 2 approaches. 
      1. First you can put CDATA in the elements manifest within Module - File - AllUsersWebPart structure. I ran into problems with this approach trying to get the correct attribute values for the Module and File elements, and I cannot find enough guidance on this. A example of what I am talking about is on Andrew Connell's blog. (Most of the posts on deploying webparts onto pages is to do with Publishing pages, but I'm working within the confines of WSS)
      2. Or, as Jeremy Thake suggested to me, you can include the webpart DLL as a reference in the VS solution, and then use a feature receiver and a SPLimitedWebPartManager, as demostrated here. I got this working well when I manually activate the feature, but when stapled to a site def, it seems to be attempting to use the webpart manager before the site is fully provisioned.
    • So, my questions would be...
      1. What are the pros and cons of these two approaches, and do they give you the exact same end result?
      2. Where can I get more info on what the attributes of the Module and File elements in the first approach should be?
      3. Up until now, on our prototype site, I've manually added the webpart from the gallery. When I change the webpart dll definition (to display different data for instance) the change is reflected in the webpart already on the page. What will happen in the second approach above? I've now added my webpart dll as a reference within this feature solution. So when this dll is deployed and used, does it use the most up to date version in the GAC, or has it effectively got a snap-shot of the webpart dll at the time it was added to the project, and then uses this to work with?
      4. Paul Liebrand suggested one way of dealing with the timing problem while feature stapling, but I couldn't get it to work for me. He suggested that a more elegant way would be to use the SPWeb.Provisioned property, but I'd like to see how I'd use this approach. Any other guidance on dealing with this "race-condition" would be appreciated.
      5. I noticed several weird things when going to edit a site's main page that had several webparts added using the second method above. If you select "edit page", none of the webparts appear in the zones to be deleted etc. When you exit edit mode the page appears blank, like before the webparts were added. If you refresh the page they magically re-appear. Can anyone explain what is happening here?
      6. If I want to remove the webparts in the FeatureDeactivating event code (assuming the use of approach 2 here) how do a reference the webparts to delete them - has anyone got some sample code or example of this? (This is especially necessary if I cannot delete them via the edit page, as explained in the above point.) 

    1. Dec 17, 2008

      Donovan Regel says:

      In relation to question C above, I seem to have answered this myself by doing a ...

      In relation to question C above, I seem to have answered this myself by doing a quick test. I made a simple change to one of the wbeparts and redeployed the solution. Both existing pages displaying the feature-inserted webparts, and new sites for which the feature is activated, display the updated version of the webpart. I'm not sure of the internal mechanics, but the changes flow through.

    2. Dec 17, 2008

      Jeremy Thake says:

      a) I've elaborated a bit more on the SharePoint Web Parts page with some pros an...

      a) I've elaborated a bit more on the SharePoint Web Parts page with some pros and cons which I hope others will start to expand on and provide more approaches too.

      b) take a look at what is building up on the Creating Features page.

      c) you need to remember to remove the .webpart using Feature Receiver code as it doesn't clean up by itself if you deactivate feature deploying it using either of the two approaches. That is why I prefer doing it all in FeatureReceiver so its in same place.

      e) again the SharePoint Web Parts page will start to ellaborate on how web parts integrate with its page and the pages page layout etc.

      f) yes, removing web parts using FeatureReceivers is covered in my sample code in my eight part series ... I'm scheduling to migrate all that to the wiki very soon!

      Great questions BTW, keep them coming!

    3. Jun 19, 2009

      Blake Blackshear says:

      d)  To handle the race condition, I followed the below blog post to write a...

      d)  To handle the race condition, I followed the below blog post to write a generic provider that I can use with any site definition.

      http://weblogs.asp.net/paulballard/archive/2007/04/09/creating-a-custom-sharepoint-2007-portal-site-definition-using-the-portalprovisioningprovider-class.aspx

      Anyone have a better solution?

  2. Feb 10, 2009

    Anonymous says:

    I'd welcome feedback on Raymond Mitchell's 'Provisioning' approach to Site Defin...

    I'd welcome feedback on Raymond Mitchell's 'Provisioning' approach to Site Definitions.
     
    I've added my own 'Feature' preference to it and blogged on it here: http://www.sharepointblogs.com/mossms/archive/2009/02/09/template-that.aspx 

     
    Kind regards, Mike MOSSuMS Stringfellow

  3. Feb 13, 2009

    Andrew Burns says:

    I think it's worth noting that several of the 'authorities' on the subject are t...

    I think it's worth noting that several of the 'authorities' on the subject are tending to the 'minimal' site definition and features approach. Joel Oleson has a good summary of the discussion

  4. Mar 09, 2009

    Mike 'MOSSuMS' Stringfellow says:

    I've added a couple of external links to this wiki to help the discussion. Fir...

    I've added a couple of external links to this wiki to help the discussion.

    If you have something to add, or disagree with what you see, let us know!

  5. May 09, 2009

    Anonymous says:

    An article on Sharepoint Site Templates http://dotnetdreamer.com/2009/05/09/int...

    An article on Sharepoint Site Templates

    http://dotnetdreamer.com/2009/05/09/introduction-to-site-templates/

  6. Jun 29, 2009

    Anonymous says:

    Site Template is most encompassing when using a "permissions setting" workf...

    Site Template is most encompassing when using a "permissions setting" workflow in that site template.

    You can use the GUI and SPD and VS to get the site look and feel correct, Then simply correct the fact that the
    Site Template does not apply the same permissions with a once built workflow. (you also have to manualy set the incoming email address of lists I believe on the new site.)

    Sites generated from a Site templates are full fidelity snapshot clones except for permissions, that includes all content, and GAC deployed workflow automatic list associativity.
    Running the permissions workflow on the newly created site and the "except for permissions" limitation is removed.

    Not one bit of XML editing.

    I don't understand the CON mentioned above about Content type visibility. But part of the reason for moving to sharepoint was to get away from
    content "stereo" typing. So I have not yet run into any limitations yet, Content types are just a filter patch when trying to add relational structure to lists. Better to organize you information such that content types are not needed.

    1. Jul 01, 2009

      Anonymous says:

      I wrote "Site Template is most encompassing when using a "permissions setting"&n...

      I wrote "Site Template is most encompassing when using a "permissions setting" workflow in that site template."

      Should say "Site Template is most encompassing when using a "permissions setting" workflow AND a "feature activation" workflow in that site template."

      Obviously they could be a single "complete the clone" workflow. I guess my point is.... it depends.

      The limitations in each reuse attempt all seem like workarounds to a mature product.

      Click HERE to build an exact copy of this web under a new name. Is the functionality that is needed.

  7. Jul 03, 2009

    Anonymous says:

    The current version of SharePoint portal does not provide template controls that...

    The current version of SharePoint portal does not provide template controls that all the ASPX files refer to... but with master pages on the way through ASP.NET 2.0 hopefully that will change! Site definition file changes have to be done to every affected file in that definition.
    Thanks different kinds of poker games 

  8. Jan 07, 2010

    Hynek Cihlar says:

    A completely new approach with no cons would be provisioning the site collection...

    A completely new approach with no cons would be provisioning the site collections with Mossquito, No need to code C# or XML definitions, no need to create features or WSPs. Simply build the structure in a full-featured GUI and deploy to as many environments as desired.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Hosted generously by CustomWare