Creating a Feature to update the Web.Config

Creating a Feature to update the Web.Config

I just wrapped up a feature that will update the web.config with custom settings. I did it by creating a feature receiver that loads web.config modifications from an xml configuration file and then applies them using the SPWebConfigModification class.

The entire process is straight forward. There are few subtle nuisances to SPWebConfigModification that make it tricky.

Below is some sample code from my Feature. The ApplyWebConfigChange is responsible for creating an entry to the web.config.

private void ApplyWebConfigChange(SPWebApplication webApp, string ConfigurationChangeIdentifier, string ConfigurationName, string ConfigurationXPath, string ConfigurationValue)
{

Collection modsCollection = webApp.WebConfigModifications;

SPWebConfigModification configMod = LookupModificationEntry(modsCollection, ConfigurationChangeIdentifier, ConfigurationName, ConfigurationXPath);
if (configMod == null)
{
configMod = new SPWebConfigModification(ConfigurationName, ConfigurationXPath);
configMod.Owner = ConfigurationChangeIdentifier;
configMod.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
modsCollection.Add(configMod);
}

configMod.Value = ConfigurationValue;
webApp.Farm.Services.GetValue().ApplyWebConfigModifications();
webApp.Update();
}

The first step is to reference the collection that contains a list of SPWebConfigModification objects. This collection is accessed via the SPWebApplication.WebConfigModifications property.

The next step is to see if the change already exists in the WebConfigModifications collections. If it does then all I want to do is update it. If it is not there then I want to create it.

When creating new entries it is extremely important to make sure the SPWebConfigModification.Name is unique within the SPWebConfigModification.Path. If the name is not unique within the context of the path then you could end up with duplicate entries and you will not be able to remove the entry with SPWebConfigModification.

Tip: Get very comfortable with XPath since both the Path property and Name property have to be valid XPath syntax.

Make sure the Owner property is set to a unique value for your change. Later I will provide a quick and easy way to remove changes from SPWebConfigModification collection. My technique assumes that the Owner is unique for each modification.

Tip: Always set Type property to SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode. The two other options "EnsureAttribute" and "EnsureSection" will permanently change the web.config (as in you can never remove the items, even if you manually remove them they will return)

The last step is to call the SPWebService.ApplyWebConfigModifications and SPWebApplication.Update. Since my web application is deployed across multiple web front ends I need to call the ApplyWebConfigModifications. This routine will make sure the web.config change is made on all web front ends. If I only had one web front end then I could have just called SPWebApplication.Update.

Removing Web.Config Changes

Removing entries is really simple if you can assume that the Owner property is unique per change. In the routine below you can see that I will go through each item in the SPWebConfigModification. When I find an entry with the Owner set to a certain value I will remove it.

private void RemoveWebConfigChange(SPWebApplication webApp, string ConfigurationChangeIdentifier)
{

Collection modsCollection = webApp.WebConfigModifications;

SPWebConfigModification deleteModification = null;

foreach (SPWebConfigModification mod in modsCollection)
{
if (mod.Owner == ConfigurationChangeIdentifier)
{
deleteModification = mod;
break;
}
}

if (deleteModification != null)
{
modsCollection.Remove(deleteModification);
webApp.Farm.Services.GetValue().ApplyWebConfigModifications();
webApp.Update();
}
}

Here is an article that covers some more problems with SPWebConfigModification in more detail.

I learned a lot of great information about SPWebConfigModification here.

View the original article here