DotNet Development, SharePoint Customizing, Silverlight, MS Infrastructure and other tips and tricks

SharePoint Solution Deployment merging web.config content

Posted by PANVEGA on April 16, 2007

Many WSS solutions I have created have included Sitemap modifications, resource files and various web.config changes. When deploying the solution to the farm, these changes don’t get automatically merged into any existing web applications even you restart the IIS machine. I have come across two ways to modify the web.config with custom nodes when using SharePoint.

If you wanna deploy ASP.Net pages to Sharepoint and you e.g. have to add you custom tags to the web.config.

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.

However, this approach will not modify existing web applications.

<add key=”Password” value=”password”/>
<add key=”Domain” value=”myDomain”/>

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.

Add the file to a solution. A file to be deployed to the CONFIG folder can be inserted by using the <RootFile> element.

In your manifest.xml you only have to add your custom webconfig.merge.xml like:


<RootFile Location=”CONFIG\webconfig.merge.xml” />

<!– rest of solution manifest here
<FeatureManifests>… and other elements–>

After the deployment use stsadm -o copyappbincontent command and all your new configurations you packed into the webconfig.merge.xml are now merged to your deafult SharePoint web.config file.

The actions defined in the .xml file are applied to the configuration settings of the Web application. A major advantage to using an .xml file to supplement the Web.config file is that customizations are not lost when Windows SharePoint Services is upgraded and the Web.config file is overwritten.

The copyappbincontent Office SharePoint Operation copies Web application–specific files, such as page resource (*.resx) files from their respective locations in the 12\CONFIG folder to the correct location in each Web application on the computer. The copyappbincontent operation does not take any parameters.


Changes that you make to Web.config may be overwritten when you install updates or service packs for Windows SharePoint Services, or when you upgrade an installation to the next product version.

Another approach:
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();


Remove values from the web.config

Instead of adding a new tag to your web.config path, you can also remove every value you want. Use the “remove” with a XPATH query.

In this example I wanna check the tag “trust” in the node system.web where the attribute “level” is equal to “WSS_Minimal”. The remove value is set to a comment tag:

<!–<trust level=”WSS_Minimal” originUrl=”” />–>

<remove path=”configuration/system.web/trust[@level=’WSS_Minimal’]” />
<add path=”configuration/system.web”>
<trust level=”Full” originUrl=”” />
<add path=”configuration/system.web/securityPolicy”>
<trustLevel name=”Full” policyFile=”internal” />


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: