Specifically, if my code makes a change to the web.config to enable the ScriptResource.axd HttpHandler, and then another third party app comes along and also 'adds' the config entry (it doesn't add a duplicate, but if my code wasn't there before it would have added the entry), and then my feature is deactivated, how does (or does) SP know that other features also need that entry to even though my feature wants to remove the HttpHandler from the web.config?

I am using SPWebConfigModification to made my config file edits, and it works just fine when my code is all on its lonesome, but I noticed the other day that another third party is also using the ScriptResource.axd and when our feature (web app scoped) is deactivated the resource entry is removed, breaking the other party. I have deployed this solution to several dozen other farms and this entry was remembered/left alone but for this one farm is not. Could I make edits to the web.config.old files to maybe get SP to remember that other features also need the entry?

I am toying with the idea of changing my web app feature to not auto activate so I can at least have some guarantee for our customers that we won't break their other tools, but there are tons of dependencies on the stuff this feature does so I am not looking forward to all the regression testing...

1 Answer 1


web.config.old files are nothing but txt backups. SharePoint is not tracking these at all. It will keep track of modifications done via SPWebConfigModification, but only in as far as keeping track of "current" modificaitons.

Have you looked at supplemental config files? Instead of modifying the web.config directly, you can deploy a supplemental file to make those changes. This file will "merge" the custom config with the file that is created from the settings stored in the config database. When you deactive the feature, you remove this file, re-run the stsadm command to re-create the web.config, and your settings should be gone. If a 3rd party uses a different approach (i.e. SPWebConfigModification), then their entires should be added by SharePoint from the config database. The downside is you need to kick this off on every server to recreate the web.config.

This is theory on my part, I've not tried this approach.

Here is your MSDN refrence: http://msdn.microsoft.com/en-us/library/ms439965.aspx

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.