When to use Custom Site Definitions… and not

Question

Its an old battle between ITpro and developer. ITpros hate them due to upgrade issues, devs like the freedom it gives them without having to do house cleaning with feature stapling.

What is your preference, and when do you use what?

When you stick with OOTB SDT how do you add your customizations?

Personally i tend to only use custom SDT when doing WCM (to get ID), or in rare cases when an intranet sub site collection needs to be cleaned up for excessive artifacts.

Lately when i customie OOTB STD i prefer custom provisioning providers (on both root site and sub sites) in combination with feature receivers for maximum flexibility. On my latest project we even did a general CPP that could be configured using XML where you could set up default pages, what sub site templates and page layouts should be visible, instantiate lists and list items programmatically, what web parts to provision, different configurations like audit enabling, navigation configuration, role definitions etc.

Let me know your favourite way of doing this, and why you prefer doing it like that.

[Marked community wiki]

Answer 1

Ok so in SharePoint 2010 there is a new player on the field: Custom Web Templates.

I am now using them almost exclusively, instead of custom site definitions.

Web Templates offer a few benefits over custom site definitions:

Pros

• manifests can be upgraded (this is not supported on site defs!)
• can run within the sandbox and hence be used for SharePoint Online (site defs cannot!)
• support both farm and site collection scope for granular deployment
• better upgrade promise since site appears to have been created with OOB site definitions

Cons

• still a bit buggy! Locale and Subweb attributes currently does not work
• feature stapling does not work (as there are no ID to pin it on), this isnt really a problem since you can edit onet.xml in a supported way...
• no OOB way to determine what web template was used to provision a site (set an id yourself on web properties)
• not supported for Site Variations

For SharePoint 2010 custom web templates should be your default choice! There are situations where you would still use custom site definitions, but the list is short.

To learn more on custom web templates read these two articles by Vesa Juvonen:
Site definitions vs Web templates
SharePoint 2010 and web templates

Answer 2

The perfect site definition is empty. The built-in templates are useless in anything but the simplest solutions. Even if the customer wants exactly what is in the team site template, I still rebuild that as a WSP solution and deply using code.

Code is the way to go, because it gives a mix of what the administrators want and what the devs need. the latter is more important as a good dev will make the admin job easy.

Upgradability is also rarely a real issue, as it is easier to create a new solution rather than work around the issues of upgrades in WSS3. WSS4, however, vastly improves upgradability and introduces feature versioning to allow for multiple version of the same feature running at the same time in different sites.

I think I'll actually write a blog post on this...

.b

Answer 3

I'm programmatic all the way. At TechEd Australia 2009 I presented on this topic, still waiting for the web cast to go live. Would recommend watching it, watch my blog for the announcement.

Just to add to this discussion the SharePointDevWiki has two relevant pages: CAML vs Programmatic Code Sites Templates vs Site Definitions vs Features

Answer 4

Currently i prefer working with the "minimal site def" just to get an Id, and then use receivers to add the cool stuff. This is mostly due to the fact that I think I get the job done faster and that you can upgrade the solution easier (and in a supported way).

I wrote a piece on this a couple of days ago Avoiding Xml Based SharePoint Features - Use The API Way.

Answer 5

When doing publishing sites (WCM) I think you really need to use a Site Def, if for nothing else to get an ID, but otherwise I like to keep it empty and use features for everything else, usually coding feature receivers to do the bulk of the work.

Over the summer though, I was starting to get convinced by some very smart SharePoint designers that there may be some benefits to letting them hack up ONET and write lots of declarative CAML-- the premise here is that even though it's easier for ME to write feature receivers, in the context of having a designer/branding expert doing publishing sites, it may actually be easier for THEM to modify things declaratively than to write C# code. I dunno, haven't actually tested this theory yet.

What I don't buy though is the notion that you shouldn't use site def's because it'll make upgrading harder. While this may have been true in the past, there were all sorts of things that made upgrading harder that don't get knocked nearly their fair share.

Answer 6

I like to use both Site Definitions and Features to deliver content. I just have to weigh what is needed for the job. If I know the requirements for the web are going to be contained on a few lists, I'd go with one feature and use the OTB site def. If the web is completely customized or needs many features, I'd start with a site def that closely matches my base functionality and then write some features to deliver the rest. The site definition should be used to deliver stuff that a feature is harder to do like different master page, theme, default.aspx, etc. It is better for ITPro to use my site definition to build that web then figure out what features to activate and in what order. Now with features the CAML and receiver code is a balancing act. Sometimes you can do it up in CAML but its faster to write in code or vice versa. I believe declarative CAML is easier to capture for source control and server tweaking, but not everything can be done in CAML like web part connections and instancing some web parts. Whenever you have the opportunity to define your own ID, do it -- it makes support and extensiblity so much easier.

Answer 7

Personally, I prefer going with a lean Site Template and then using Feature Stapling. I usually create one parent feature which has activation depedencies on several child features. I then staple that parent feature onto whatever site definition. The reason I like this is that I can deactivate and reactivate the feature to update the existing site. It also allows me to create quite a bit using CAML and minimal coding.

Answer 8

I'm using SPWebProvisioningProvider all the time to have control what features to activate when and in the order I want. Is more easy I think to devel and debug site and lists provisioning then using ONET.XAML and CAML.

Answer 9

One reason I use Site Templates (and I echo the details above to keep them clean and link features) is that I like the end user experience of selecting My Custom template from the Create Sites page. Adding new WEBTEMP files is easy, copying a blank site template and modifing it is easy. It allows the project (if it needs a custom template) to get up and going quickly, yo get the first WSP automation done quickly and work through the whole dev lifecycle, before needing to dig into any C# code.

If the project required that I need to modify the OOB site, for example MySite, then i would always go the feature stapling route.

Answer 10

I developed my own little framework (too big word) to achieve complete upgradability of my solutions. This was major issue for most of my clients.

In short: I am feeding my framework on feature (de)activation with some very simplified CAML definitions and I have covered in code most of the commonly needed stuff (adding/upgrading lists, receivers, content types, site columns etc.). By changing my definitions and by reactivation of feature I can easily make needed upgrades to already deployed solution (that was one of the main goals). I am using additional code in feature receiver to do all other 'stuff' that isn't covered by my framework.

I like it to do this way because by using code I am in full charge of everything, I can easily find errors, I can solve even some complex scenarios in very short period of time and I can reuse any solution with ease.