Slinger's Thoughts

October 22, 2009

Where do you scope your SharePoint features?

Filed under: SharePoint — slingeronline @ 8:21 pm

I had something occur recently that got me to thinking about SharePoint features, and where they are scoped.  For the uninitiated, you can scope features at four different locations. There are a myriad of articles out there that tell you how to make a basic feature, how to create the feature and element files, and how to associate your feature to the various components of SharePoint.  They tell you how, but I haven’t seen anything that makes any recommendations on where your feature should be scoped.

Now just because I haven’t seen anything doesn’t mean that it’s not out there, and if it is then I apologize, but I thought that something should be said anyways.  I’m starting to see possibly some amount of pride in ones work, that bleeds over and affects those of us who are trying to use those most awesome features that some developer had the grace and good sense to share with us admins.  The problem is, it seems that just about every feature out there is scoped for a site collection or a web application.  What if we only need that kick ass feature for one site, and really don’t want it anywhere else?  Doesn’t leave much room for an admin to go does it?  We are going to break your feature trying to get it only where we want it, or we are going to find someone else’s feature to use instead, that probably doesn’t do exactly what we need it to do, but merely comes close.  What comes after that is usually a string of profanities aimed at developers.  In my personal opinion, I think it would be best to scope every feature at the lowest level.  I guess as sort of a least common denominator type of thing.  If we need the feature on more than one site, we can add it there.  Obviously not every feature can be scoped at the site level.  Some will need to be scoped at the site collection level, some at the web application level, and some at the farm level, depending on what the feature does.  For the most part though, most of the features I have encountered affect the site level, but are scoped at the site collection level or higher.  Great, now I have a feature that I wanted installed and activated for one site, installed and activated on every site.  Thanks.  Your feature just became useless to me. 

I think it would be really nice if there was a way that administrators could change the scope of a feature so that they could deploy it where they need it, and only there.  Some may need a feature that is scoped for the site level installed across their entire farm.  That may not be fun to install a feature and then activate it 177 times to get it everywhere they want it.  Why not make it so that we as administrators can choose the scope we want the feature deployed to?  Sure, we can go in and edit the feature.xml or element.xml files, but some administrators have limited or no access to the actual server, and I know of at least one instance where the administrator is forced to work through web interfaces alone.  They are unable to run an STSADM command on the server, and cannot change those files. 

I have a request for our developers of features out there; don’t over scope your feature.  And if you do scope it higher than a site, why not add a comment in the feature.xml as to why? I’m not a developer, but even with the little bit of coding that I have done, I commented the holy hell out of it.  Even in config files, comments are crucial. Just add a comment somewhere in the file, that states why.  Here’s something else that would be completely cool for a developer to figure out.  Create a feature installer that doesn’t pack the feature into a WSP file. (Which if I understand correctly, scopes the feature for a web application automatically.) Here’s a thought that would make it infinitely easier on us admins.  When you make that solution to install features, read the feature.xml to find where the feature is scoped, and make that the “minimum” scope, and allow us to choose where we want to scope the feature.  Check boxes or a drop down list would work nicely. 

In any case, I’m seeing all too often the “over scoping” of features in SharePoint, and it doesn’t always make our job easier as administrators.  It would really help me out, and many of the other administrators I’m sure, if you guys kept the scope down to the site level wherever possible. 

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

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

Create a free website or blog at WordPress.com.

%d bloggers like this: