Which Feature Scopes are right for me?

Question

I'm developing a site using SharePoint Server 2010 in Visual Studio 2010. I'm having trouble determining which Feature Scopes are right for my features.

1. I have a feature which includes a custom Master Page, custom CSS for this master page and modifications to the ribbon. The entire site will use this master page and this CSS. Is the Site scope right for this? Or should I use the Web Application scope?

2. I have a feature which includes custom Page Layouts. Most pages on the site will use one of these page layouts. Is the Site scope right for this? Or should I use the Web Application scope?

3. I have a feature which includes custom Visual Web Parts. Most pages on the page will contain one or more of these web parts. Is the Site scope right for this? Or should I use the Web Application scope?

Currently I'm going for the Site scope for all of them, since I have no real instances of anything in my features - just definitions. But since either scope works fine when developing and deploying from within Visual Studio 2010, I find it hard to determine which scope is right - and to perceive the implications of the differences between the scopes. And perhaps the Web Application scope - or even the Farm scope - would be more right for one or more of these features?

(I have no idea what the deployment scenario looks like in terms of farms, servers, sites and so on. I would like for my features to work regardless.)

Answer 1

1) Yes, probably. If you deploy it to the Master Page Catalog in the root web of a site collection, you can choose to use it in subsites still, if you want. I would only use Web scoped for this if I had an unusual and rarely used master page that I wanted to use in a web.

2) Yes. It'll get deployed to root web in your site collection (like the master page).

Both the above don't make sense as WebApp level features, as where in the virtual file system would the files be stored? There is no 'library' like the Master Page Catalog to put these in, and they're not Application pages.

3) is more complicated. It should be at Site collection scope, as the .webpart files will need deployed into the Web Part Gallery in the rootweb - and like 1 + 2, there is nowhere at the WebApp level to store those files.

However, you should be aware that there will be other resources deployed (e.g. user controls into ControlTemplates, if I remember correctly).

My rule of thumb - Only go above Site if you've got something that clearly MUST be above Site (e.g. a TimerJob).

Answer 2

This all depends on your requirements. Some elements will work fine in multiple scopes, but it depends how you intend your features to be used.

Enable something at site collection (Site Scope) and it'll be available to the entire site collection including all it's sub websites.

Enable something at Web Application level and it goes one step higher, available to all site collections.

Enable something at Web level and it'll only be available to a specific web, and not switched on by default to any child webs created within.

Feature Scope confusion is quite common, so don't feel overwhelmed.

This blog post has some good explanations of the different levels, but beware it's targeted at WSS3, so the stsadm commands are deprecated in SPF2010, but the general idea of what each scope does is still valid.

http://www.etechplanet.com/blog/understanding-scope-of-sharepoint-features-(wss-30moss-2007).aspx