Opinions Wanted: My Approach to Creating Site Definitions

I want to share with you my approach to creating site definitions. I've received mixed reactions at events and would love to hear your thoughts.

Over the last few weeks and a few times at the Office Developer Conference 2008 this past week in San Jose, CA I have been approached with questions about my approach to creating site definitions. The reaction I get is usually mixed so I thought it would be interesting to see how others feel about this approach. Keep in mind that this is by no means a stated recommendation… it is simply my approach.

Thinking back to my days in the WSS v2 / SPS 2003 timeframe, I recall sitting in a class learning about site definitions,picking through all the CAML and also reading a few books. The reaction was always nausea… I hated them as they were just so big, bloated, and frankly, too damn hard to create and perfect. I did everything I could to avoid them like the plague. Unfortunately they are a necessary evil that we can’t completely ignore; you must have a site definition to create a site.

What about v3?

First, I still do everything I can to avoid creating site definitions. They are too big and cumbersome making it hard to debug when problems arise. Most importantly, they are very inflexible; once one a site has been created off a site definition, it should never be directly changed. The most you can do to a site definition after a site has been created off it is to use Features to modify the sites or even staple Features to the site definition. But there is no way to remove functionality from a site definition. Consider if a site definition activated a Feature that created a list template. What if you don’t want that list template? You can’t remove it unless you do it through the API, but the list template will always be created… you are simply doing cleanup work. Sure, site definitions are much easier than they were in v2 with the addition of Features and the global site definition.

But there are times where it is just simply unavoidable to create site definitions. We just need them at times. In those times I go with the minimalist approach… I like to think of it more like the v3 approach. I take a copy of the blank site and strip it way down… no TeamCollab Feature, no WSS branding image… nothing… a truly blank site. I then give it a new name and ID. At this point I’m finished with my site def… but what about adding the required functionality I need for a project? I take all of that and embed it within Features and then create associated stapling Features that are used to attach them to the site def. This approach allows me to create site definitions very quickly and makes them much easier to debug and develop. More importantly it provides me much more flexibility than the v2 approach. I can easily remove functionality by deactivating existing Features or even remove functionality from future sites by deactivating the stapling Feature.

Most of my customers seem to like this approach. I’m curious how many other people are doing this, or prefer this approach…

Andrew Connell
Developer & Chief Course Artisan, Voitanos LLC. | Microsoft MVP
Written by Andrew Connell

Andrew Connell is a web & cloud developer with a focus on Microsoft Azure & Microsoft 365. He’s received Microsoft’s MVP award every year since 2005 and has helped thousands of developers through the various courses he’s authored & taught. Andrew’s the founder of Voitanos and is dedicated to helping you be the best Microsoft 365 web & cloud developer. He lives with his wife & two kids in Florida.

Share & Comment