Yes, I know that we have the standard SharePoint SPWebConfigModification class and also the stsadm CopyAppBinContent command. But … the problem is that unfortunately there’re cases when they just can’t do the job the right way causing reasonably some frustration. When I thought about these problems I came to the conclusion that spending a couple of hours and with some two or three hundred lines of code I may possibly achieve the same thing – and this is the solution that I came up with (possibly one in a row of many already). It’s pretty simple and does both things in one piece of functionality (a feature with a custom feature receiver that is) – it can simultaneously apply changes to the web.config files on all servers in a farm and also can copy files to the physical location of the selected SharePoint web attention (not just store files).

So, let’s get right to it:

This is a sample feature.xml file of the feature that modifies the web.config and copies (really xcopies) files to the web attention’s physical folder. You can see the custom feature receiver class specified in the feature classification – the receiver checks the properties of the feature classification and starts a custom timer job passing the values of these properties to it. It is the custom timer job that runs on all servers in the SharePoint farm that implements the aforementioned functionality.

And here is a small description of the feature’s custom properties:

• ConfigChangePath – specifies the path (relation to the feature classification path) of the xml file with the changes that should be applied to the web.config of the target web attention (I’ll describe its machinate in a small while) – the property is discretionary.
• WebAppSourcePath – specifies the path (relation to the feature classification path) of a folder whose contents (files and sub-folders) will be hackneyed recursively to the physical folder of the target web attention – the property is discretionary.
• UrlZone – specifies the URL zone of the target web attention – you may need this property only if you have an extended web attention. The property is discretionary and if you don’t specify a value the Defaulting URL zone will be used. You can specify more than one URL zones in the property like Defaulting|Custom|Internet (by the ‘|’ character as separator). Then the web.config modifications and the web attention files will be hackneyed to all IIS web sites’ physical folders of the extended web attention.

Note that the Scope attribute of the feature is set to WebApplication. This is really not a requirement and the scope can be set to Site or Web as well – the feature receiver can handle all scenarios.

The image above shows the folder structure and the files of the sample feature. You can see that the 80 sub-folder of the feature folder contains an App_GlobalResources sub-folder with one store file in it.

And a sample web modification XML file looks like:

The web.config modification XML comes with a custom XSD – you can use it in Visual Studio for intelli-sense and validation support and the XSD file should also be deployed to the 12\TEMPLATE\XML folder of the SharePoint installation since the timer job uses it to validate the input XML file.

The elements of the custom web.config modification XML are mostly self-explanatory. You will notice that the modifications that can be applied to the web.config work only on XML elements (not XML attributes) and the parent element of the element(s) to be inserted should exist in the web.config file.

The ParentElementXPath attribute of the ConfigItem element contains the XPath that will be used to locate the parent element of the element that should be added, updated or deleted – as I already mentioned this element should exist in the web.config. The ElementXPath attribute contains the XPath that will be used to locate/identify the element to be made/modified – note here that the XPath for it is relation to the parent element. The third attribute of the ConfigItem element is the CreateOption one – it has three possible values:

• Add – this will make a new element, if the element already exists it won’t get overwritten
• AddOrReplace – this will make a new element or overwrite the element if it exists
• Remove – this will delete the element if it already exists

As you see the functionality provided is pretty basic and simple but as I said before the code is really small and straight-forward and can be reasonably easily modified or extended.

The custom solution can be downloaded from here.

Check it out:Stefan Stanev’s SharePoint blog