Change
If you've ever worked with SPWebConfigModification, you'll be glad to know that in SharePoint 2010, removing modifications from a Web Application now covers all URL zones, not just the Default zone - thank you Microsoft!
Caveat
SharePoint development in Visual Studio 2010 is a huge time-saver compared to earlier versions, since deployment automatically handles adding/retracting Solutions, activating/deactivating Features. That auto-activation can be awkward with SPWebConfigModification though, because Visual Studio will auto-activate a WebApplication-scoped Feature for all Web Applications. Yep, that means if SPWebConfigModification is used in a WebApplication-scoped Feature (standard practice), and deployed through Visual Studio 2010 in the usual iterative development fashion, every web.config in the entire Farm will get those web.config modifications, except Central Admin's and the built-in STS's. Probably not what you were hoping for...
A couple of workarounds:
Change the SPWebConfigModification Feature's Activate On Default property to false, deploy, then manually activate the Feature from Central Admin or PowerShell.
During development, temporarily change the Feature's scope to something else, alter the Feature receiver to deal with the scope change, and continue with development as usual. That way, development deployment is still automated, and web.config modifications can be contained to just the targeted Web Application. But, depending on what kind of web.config changes are being made, it may or may not be possible to manually activate/deactivate the Feature at the new scope, should that be needed.
To surface the Feature's Activate On Default property in Visual Studio's Properties window, double-click FeatureName.feature in Solution Explorer. (A single click on FeatureName.feature will show the Feature file's properties.) |
|
Code
A web.config backup for all zones
Corrupting a web.config is not a pretty prospect, and best avoided, so here's a bit of code to drop in any Feature employing SPWebConfigModifcation. This backs up web.configs in all zones of the Web Application passed to it, labeling each backup with the date and time.
private void BackupWebConfigs(SPWebApplication webApp)
{
try
{
foreach (KeyValuePair<SPUrlZone, SPIisSettings> pair in webApp.IisSettings)
{
SPIisSettings iisSettings = pair.Value as SPIisSettings;
string webConfigFolderPath = iisSettings.Path.FullName;
string webConfigFilePath = webConfigFolderPath
+ "\\web.config";
// result similar to web2011_2_1_19_24_14.bak
string webConfigBackupFilePath = webConfigFolderPath
+ "\\web"
+ DateTime.Now.Year.ToString() + "_"
+ DateTime.Now.Month.ToString() + "_"
+ DateTime.Now.Day.ToString() + "_"
+ DateTime.Now.Hour.ToString() + "_"
+ DateTime.Now.Minute.ToString() + "_"
+ DateTime.Now.Second.ToString()
+ ".bak";
System.Xml.Linq.XDocument webConfig =
System.Xml.Linq.XDocument.Load(webConfigFilePath);
webConfig.Save(webConfigBackupFilePath);
}
}
catch
{ }
}
PowerShell
PowerShell is a great way to test SPWebConfigModifications, and when it's necessary to cleanup a few stray modifications that got away, PowerShell to the rescue! Here are few examples to get started:
# Example: list all WebConfigModifications for the intranet Web Application
$wa = Get-SPWebApplication http://intranet
$wa.WebConfigModifications
# Create a new modification, add, and apply
$mod = New-Object -TypeName Microsoft.SharePoint.Administration.SPWebConfigModification -argumentList "add[@key='Frodo']","configuration/appSettings"
$mod.value = "<add key='Frodo' value='was here' />"
$mod.owner = "Test"
$mod.sequence = 0
$mod.type = [Microsoft.SharePoint.Administration.SPWebConfigModification+SPWebConfigModificationType]::EnsureChildNode
$wa.WebConfigModifications.Add($mod)
$wa.Update()
$wa.WebService.ApplyWebConfigModifications()
# Remove all modifications for owner "test" (case-insensitive compare)
# Count backwards in the loop, to avoid index-out-of-range issues caused by
# modifying the collection while iterating over it
$mods = $wa.WebConfigModifications
for ($i=$mods.count-1; $i -ge 0; $i--) { $m = $mods[$i]; if ($m.owner -eq "test") {$mods.Remove($m)}}
# Here's a more fun way to write that last line, using the range operator:
foreach ($i in ($mods.count-1)..0) { $m = $mods[$i]; if ($m.owner -eq "test") {$mods.Remove($m)}}