"Guru of governance?"
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.
So thanks Mike, I’ll leave all that XML serialisation stuff to you – as I only barely got my head around that in the JavaScript series. So long as it’s web application scope you can do what you like…
Hey, great site.
Couple things,
Some of the html on your site seems to refer to localhost. A view source reveals: http://localhost/wordpress/wp-content/themes/stardust-v10/images/wordpressicon-hanttula3.jpg
Also, I have a question as I’m out of my depth on Sharepoint server architecture and config (and was hoping you might help).
I’m writing a web part which requires config settings (so my package would write to the web.config and deploy the web parts). The web part is only intended for use in a specific site collection. Would you still recommend writing the settings to the web.config (along with a scope set at the WebApplication level) or is there some other scope / place I should be storing these settings.
Cheers
Neil
The settings of this web part – should the site collection administrator be the one to modify them? If that is the case, one option is possibly to use a list on the top level site of the site collection for your configuration? Either that or an XML file somewhere on the root site (if its in a document library than you get recycle bin and versioning if you want it).
Your feature can then be scoped to site collection and it can create this list/config file as well as copy your web part to the web part gallery?
regards
Paul
Thanks for the response,
I thought of doing what you suggested, but couldn’t figure out how to avoid hard coding list guids or file paths into my code (i.e. the guid of the config list or the path of the xml file).
I suppose I could put the xml file into %12hive%/TEMPLATES/LAYOUTS/INC/myfolder/
Also, my deployment feature is pushing a number of files into the 12 Hive (css, ascx user control, javascript for ajax, etc). The inenvitable impact is that these become available to every site collection. So that seems to only be appropriate at the web-application (or farm?) scope. I’m using Ted Pattison’s stsdev tool which you’ve written about previously, and it seems like using the 12hive for this purpose is “best practice”, but it feels a little messy, as every sharepoint site now gets access to the underlying resources.
In relation to GUID or hard code, forget GUID I think – I’m sure you can go by name (but I don’t code full time I’d have to double check). But you can draw some comfort from some of the ideas used by the publishing feature. Upon enablement, several lists and libraries are created in the root of the site collection, meaning that it does rely on hard coded paths, relative to the site collection root.
In relation to placing files in the 12 hive, your right, it is theoretically available to any site collection, but its the solution that does this, not feature activation. Solutions are always added to the store by the farm administrator. Thus those supporting files can be placed in their correct locations via the activation of the solution by the farm administrator.
But the farm administrator chooses which web app to deploy the solution to, which is in the form of a feature. So only 1 web app would have the feature available to be activated from. (And at this point web.config has been adjusted for safecontrol and the like).
At that point, all of the pre-requisite files are in their right places, and all activating the feature does is add the web part to the gallery of the site collection, and create some of the supporting config items.
Hope this helps, its only off the top of my head though so apologigies if I get it wrong..
Really helpful, thanks. I’m keen to have something admin friendly / admin approved, and what you say about activating features makes perfect sense. With your help I think I’m on the right track now.
No problems, you have renewed my faith that app developers and governance can co-exist 🙂
cheers mate
Paul
Just a quick update to share.
turns out the use of the web.config was unnecessary (indeed inappropriate). Really I should have been using configurable web-part properties (which allow for both hard-coding AND changing). Part of the problem was I didn’t know how to get relative urls (to point to the 12hive).
The same approach for getting relative urls (SPContext.Current.Site.ServerRelativeUrl) can be used to find sharepoint objects throughout the site, so by being a litte bit clever, changes to the web.config can be minimised (which seems like a positive thing).
Thanks again.
Mike and I have talked about this topic before (he pointed me to your post) since we were thinking of very similar ideas surrounding web.config modifications. I was thinking more on this recently…Since deploying a web part required a SafeControl entry into the web config, would you recommend all web parts be scoped at the web application level?
Hey Ryan
In the case of webparts, if they are bunded into a solution (wsp file then there is no need to deal with it at the feature level. the solution manifest can make this change for you and since installing a solution is performed by a farm administrator, the security boundaies remain intact.
cheers