I came across an interesting item this morning. I need to deploy web.config changes to a MOSS 2007 farm. After hearing many people including Ted Pattison speak about this in various sessions at the Office Developers Conference, my initial reaction was "Great, now I can make web.config modifications using a SPFeatureReceiver and the SPWebConfigModification class. Additionally, this is discussed in detail here:
http://msdn2.microsoft.com/en-us/library/bb861909.aspx
and Here:
http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32
However, I began thinking a little more in depth about this and something occurred to me...If I am trying to make modifications to a configuration file so that these items can be changed without compliler dependencies, that is, with needing to rebuild and redeploy my code, why in the world would I build an assembly as a SPFeatureReceiver, strong name it, deploy it as a feature to the GAC, that just holds configuration information????? That seems to break the whole model of the purpose of a configuration file and configuration settings which are not compiler dependant.
So I looked further and found that you can deploy web.config changes to the 12\CONFIG directory.
http://msdn2.microsoft.com/en-us/library/ms439965.aspx
That really made my day, except that WSPs specifically target the 12\TEMPLATE directory and not anything above this directory such as 12\CONFIG. Now, I fully appreciate that I probably don't know what I'm talking about so if anyone can point me in the right direction regarding a managed deployment strategy for config files to the 12\CONFIG directory using SharePoint solutions, I would be more than greatful, otherwise I will build a wix installer which will accomplish the same thing, only must be run on each server in our farm.