My old mate from employers yonder, Mike Stringfellow is one of those developers who always liked to take a step back and think through the bigger picture implications of various design/coding decisions. It’s just a pity that at that particular company we worked at, he was in the minority. (Not helped by some unbelievably poor executive level management wacky views of reality).
So I became one of those bitter and twisted anal infrastructure guys who always seemed to default to "No", when asked a question. (Usually "no" was the right answer nonetheless). I was told by another colleague that some of the (web) developers were scared of me… but Mike at least understood why 🙂
He recently blogged the idea of using features to modify web.config file of a web application. After all, the SharePoint SDK offers the WebConfigModifications property (of the SPWebApplication) class. He suggested that as a governance nazi I might have issues with this idea. As it turns out I do, but only for you developers that have been slack-arsed and not done your homework! 🙂
My first question was "Does this apply to all web applications across the SharePoint farm?". Mike swore on his mother’s grave that it did (okay, in reality he said "yep"), so at least the modification is consistent (and consistency = less costly governance). So far so good…
So there is a big, big tick. (Programmers who wonder why I abuse them when they start a sentence with, "Just edit web.config…", should really go back to their true calling and instead ask pertinent questions like "do you want fries with that?" 🙂
So the next question is the squirmy one. Features are applied at 4 scope levels. Farm, Web Application, Site Collection or Site. So here is the spot test:
Which scope level do you think this feature should be applied at?
If you said "Site" or "Site Collection", go to the back of the class, you weenie! You are the sort of developer who made me bitter and twisted! The answer is of course, the Web Application scope!
Web.config is the configuration file for an ASP.NET web application. A web application can host one or more site collections. Do not assume that just because you are a site collection administrator, that you have administrative access to the web application hosting your site collection!
If you set the scope of this feature at the site collection level, you are basically allowing a site collection administrator to make a change that affects all other site collections in the web application. Uh – does the site collection administrator have access to other site collections? Probably not, so why the hell would you allow them to perform a task that impacts on site collections they have no access to? You don’t – it breaks the security model.
On your dev box, this will likely work fine, because your likely running everything as administrator anyway (double weenie!), but I suspect that in production it probably will break unless your IT guys have poorly configured your farm (triple weenies).
What a weenie filled world we live in…
Anyway, Ted Pattison is definitely not a weenie. He has blogged on this topic also and has shown in suitable detail, how to write a web application scoped feature (nice blog BTW Ted you’re definite blogroll material).
I’m going to lift one image from Ted’s blog, just to show you where web application features are enabled. You may have guessed already, that since we shouldn’t do this at a site collection administrator level, that it is done in SharePoint Central Administration by a user who has farm-level permissions or permissions for the target Web Application. (Best to stick with a farm administrator in general, I believe).
Below is the sample screen-shot from central admin, showing how you can pick a web application and then activate a feature for it.