SharePoint 2007 – 12 Hive System-File Changes: One Feature to rule them all!

Making system-file changes in “12 hive” folder of SharePoint is always a hot topic. Microsoft doesn’t recommend that unless you know what you are doing, and also has support clause against it. Despite that, there are numerous KBs at their support site which point to directions of making necessary changes by following steps that leads us to opening a file in “12 hive” and modifying to achieve the desired effect. I think – without much ado – that its important to assess what you intend to do, and when you certainly need to then there should be a manageable way to make changes to system-files that are otherwise part of SharePoint release. In my previous post I gave an example of a case when one needs to make “12 hive” changes; here are the high-level objectives…

Objectives

1. A uniform, automated, repeatable, efficient and centrally manageable way for making “12 hive” changes.
2. It should take least of coding or none to introduce changes – be it xml modification, aspx/ascx, masterpage, images, css etc.
3. It should be possible to roll-back the changes on demand.
4. It should be possible for changes to be applied to all servers in the farm, not just local.

Note: This is a standard caution that your changes to “12 Hive” may be over-written by subsequent Cumulative Updates (CU) and/or Service Packs. Hence we need to plan for this as well.

One SharePoint Feature to rule them all!

Since the release of SharePoint 2007, I’ve come across numerous tips & tricks, open-source projects, and blog posts that show how to make desired change and most often employ a code-based approach that runs on Feature Activation to open the required file in “12 Hive”, make your changes – via code - and save the file. Reverse the changes on Deactivation of Feature.

Now, one must realize that this requires significant coding effort and consistency checks (testing) to make minor changes in – say – some xml file somewhere. For example, a simple case of enabling PDF file icon support in SharePoint means creating a feature to open DocIcon.xml, parse the elements, make an entry for pdf element, and saving the xml. Many many lines of code to be written for mere single element entry. There should be a simpler way to this!

Another problem is that you have to deal with the issue that where the code runs, it will pick local file only. What about other servers in farm? You have to further write code to make changes on all servers in farm. Than there are propagation concerns to be dealt, should new servers be added to farm later.

Having said that, I think its better to have one universal and generic mechanism (SP Feature) of deploying your changes. To do that, I create a new VS project using WSPBuilder and create a SP Feature and call it HiveSwap with the idea that we’ll have a mechanism of swapping system-files with ours instead of each time writing code to directly modify/merge required files…

So you get the idea – we want to build a generic feature (to rule them all) that becomes central to us for deploying all changes by mechanism of swapping. Deliver desired files (with manual changes already in place) via feature in a solution (.wsp), activate the Farm feature and it will backup system file, replace with its own. When needing to rollback/remove, it will use backup and replace the original file back.

We need a place to keep all “12 Hive” files we want to deliver to swap system files with. I create another /12 folder inside our Feature folder. This will be a place where I just recreate the folder structure where all I want to make desired changes, copy the original file, make the changes – manually – and deploy the solution.

Before that, we need our Feature receiver to do the job of swapping files both ways on Activation and Deactivation. Here is an example code I’ve quickly put together.
Note: Consider this as pseudo code, is not production tested and you’d want to test at your end before finalizing it… (can’t share the complete/tested code for NDA)

That’s it. Your feature is ready for single-server farm. For multi-server farm, you can enhance above code to run with elevated privileges, map C$ of each server in farm (which you can get from object model) at runtime, assuming each server’s “12 hive” is same local path. Since service account is local admin on these servers, system file moves isn’t a issue.

Conclusion

I’d like to hear from readers the pros/cons of above approach, here is my take:

• Advantages
  1. Modifications are easy to do and simple.
  2. Leverage support of VS for things like intellisense for xml, aspx (partial), ascx (partial), master pages, css etc.
  3. Control over deployment/rollback with Feature activation/deactivation.
  4. Backup of system files. Should the service pack be deployed, simply deactivate the feature to bring “12 hive” to original state, implement MS changes, and reactivate.
  5. Scalable to any number of files you need to modify/replace. Lines of code has no proportionality to number of such files!
• Disadvantages
  1. All “12 Hive” system-file changes/replacements better be done by a single Feature alone. Else you may end up over-stepping with others, changing same files. If you have single administrative solution for your farm you should be okay to use above.
  2. If you are using WSPBuilder, beware of using “Copy to 12 hive” command from menu, if feature is already activated in your local Dev farm. It will simply overwrite the backup! Feature deactivation will not rollback to originals as a result.

Hope this SP Feature is productive and of use for most, if not all.

Thanks for reading.

--Sharad