Inconvenient SPWebConfigModification development with Visual Studio 2010 SharePoint Developer Tools

The new Visual Studio 2010 SharePoint Developer Tools simplify the process of developing SharePoint 2010 Solutions. By encapsulating much of the plumbing of the packaging and deployment process they enable developers to create SharePoint 2010 Solutions easier and faster. Unfortunately in some scenario this simplification comes with a price and working with SPWebConfigModifications is one of such scenarios.

The not-so-simple SPWebConfigModification

SharePoint 2010 ships with the SPWebConfigModification class which allows you to provision modifications to web.config files in a structured and repeatable way. While there are numerous arguments about whether the SPWebConfigModification class does or does not work and if it’s the way to provision changes to the web.config files, the SPWebConfigModification class is a part of the SharePoint 2010 API and is regularly being used by SharePoint developers.

Working with the SPWebConfigModification entries is anything but easy. You have to consider many different factors and have to watch out for many different things or you will end with a dirt farm and orphaned entries that will appear in web.config files all over the farm at “random”.

Inconvenient deployment of Features with SPWebConfigModifications

If you’ve been working with the new Visual Studio 2010 SharePoint Developer Tools you probably know by now, that by default, when you deploy your project, the tools will first build the project, create a SharePoint Solution Package (WSP), deploy it to SharePoint and activate the Features. One way to use the SPWebConfigModification class is from a Feature Receiver of a Web Application Feature. Depending on your project you might end up with a WSP file that doesn’t contain any Web Application-scoped files like resources or assemblies. In such situation the Solution will be deployed globally. And this is where things can go terribly wrong.

During the deployment process the Visual Studio 2010 SharePoint Development Tools activate Features by default. If a Solution doesn’t contain any Web Application-scoped resources it will be deployed globally. In such situation the Web Application Feature containing the SPWebConfigModification entries will be activated on every Web Application changing every web.config file of every Web Application in the entire Farm: not really something you wanted, right?

Working with SPWebConfigModifications in Visual Studio 2010 SharePoint Developer Tools the right way

There is however a simple trick to avoid this issue when working with the SPWebConfigModification class. If you open your Web Application Feature responsible for provisioning the web.config modifications and go to its properties in the Properties Window in Visual Studio, you will find the Activate On Default setting. It’s set to True by default what means that the Feature will be automatically activated after the WSP has been deployed. In order to prevent SharePoint from automatically activating the Feature you should set the Activate On Default property to False.

The next time that you deploy your project the Solution will get refreshed on the server and you will be able to manually (or automatically using either a post build step or a PowerShell script through CKS:DEV) activate the Web Application Feature on a single Web Application of your choice.

Technorati Tags: SharePoint 2010,Visual Studio 2010