teamleader

I have come across two ways to modify the web.config with custom nodes when using SharePoint. Yes, I know SharePoint solutions (.wsp) allow you to update web.config for safe control entries and other areas but this model doesn’t allow for any modification you want…lets say a WCF service <system.serviceModel>.

Option 1
You can use the SPWebConfigModification class that is inside the Microsoft.SharePoint.Administration.dll. Its purpose is to write nodes and attributes into the web.config file. This is a great approach when you want to deploy your custom settings via a features/solutions deployment.

SPWebService service = SPWebService.ContentService; SPWebConfigModification myModification = new SPWebConfigModification(); myModification.Path = “configuration/SharePoint/SafeControls”; myModification.Name = “SafeControl[@Assembly='MyCustomAssembly'][@Namespace='MyCustomNamespace'][@TypeName='*'][@Safe='True']“; myModification.Sequence = 0; myModification.Owner = “User Name“; myModification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode; myModification.Value = “<SafeControl Assembly=’MyCustomAssembly’ Namespace=’MyCustomNamespace’ TypeName=’*’ Safe=’True’ />”; service.WebConfigModifications.Add(myModification); /*Call Update and ApplyWebConfigModifications to save changes*/ service.Update(); service.ApplyWebConfigModifications();

 http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx

So the above code would go in a FeatureReceiver event when activated and removed when deactivated.

Option 2
If you want to write custom nodes into a web.config when the web application is first created you could also do the following.

When a Web Application is first created WSS copies the web.config file from C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG to the root folder of the Web Application. But before this file is copied it checks the CONFIG directory for any xml file that has a name in the format webconfig.*.xml and merges the contents with the web.config.

So you would create a file called webconfig.myname.xml and save it to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG

However, this approach will not modify existing web applications.

webconfig.myname.xml contents:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<actions>
<add path=”configuration/appSettings”>
<add key=”MyFilePath” value=”C:\temp\path\” />
</add>
<add path=”configuration”>
<connectionStrings />
</add>
<add path=”configuration/connectionStrings”>
<remove name=”MySqlServerConnection” />
<add name=”MySqlServerConnection” connectionString=”server=[server];database=
db];Integrated Security=SSIP;” providerName=”System.Data.SqlClient” />
</add>
</actions>

So this needs to be completed on each web front end server. So to eliminate the manual approach again you can and package this up into a solution so WSS manages the deployment across the farm.

When creating a supplemental config file, the web.config modifications are NOT automatically mergeduntil you make a call to stsadm -o copyappbincontent.

You can also force this command to be run through a FeatureReceiver.

After exploring the stsadm tool in reflector I found that the copyappbincontent operation makes a call to SPWebApplication.WebService.ApplyApplicationContentToLocalServer()'

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    var webApp = (SPWebApplication)properties.Feature.Parent;
    webApp.WebService.ApplyApplicationContentToLocalServer();
}