Wenn eine Lösung Änderungen an der web.config einer WebApplication durchführen soll, ist es sinnvoll, SPWebConfigModifications zu verwenden. Diese können zum Beispiel in der FeatureActivated-Methode des FeatureReceivers eines Features mit WebApplication-Scope hinzugefügt werden.

Hier ergibt sich zwangsläufig die Frage, wie solche Veränderungen implementiert werden können, ohne dass die SPWebConfigModifications von zwei verschiedenen Lösungen sich beeinflussen. Hierzu einige Punkte:

Kein Clear

In einigen Artikeln wird die Meinung verbreitet, man müsse vor dem Hinzufügen eigener Modifications ein Clear auf die Auflistung WebConfigModifications ausführen:

webApp.WebConfigModifications.Clear();
// add some modifications using: webApp.WebConfigModifications.Add()
webApp.Update();
webApp.WebService.ApplyWebConfigModifications();

Das darf AUF GAR KEINEN FALL geschehen. Auf diese Weise würden Änderungen, die vorher durch andere Lösungen gemacht wurden beim Aufruf von ApplyWebConfigModifications rückgängig gemacht werden!

Voraussetzungen

Eine andere Frage ist die der vorausgesetzten Knoten: Von welchen XML Knoten darf ich ausgehen, dass sie vorhanden sind? Mein Rat dazu: gehen Sie vom Minimum aus, der Knoten configuration sollte auf jeden Fall da sein, auch configSections, SharePoint und system.web sind zu erwarten, aber gehen Sie nicht von Knoten wie appSettings oder applicationSettings aus. Lieber eine Modification mehr, als nachher auf Fehler zu stoßen, weil eine Voraussetzung fehlt.

Hier ein Beispiel, wie man sinnvoll ein eigenes applicationSetting hinzufügen kann:

new SPWebConfigModification() { 
    Path = "configuration/configSections",
    Name = "sectionGroup[@name='applicationSettings']",
    Sequence = 0,
    Owner = WebConfigModificationOwner, 
    Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode, 
    Value = "<sectionGroup name=\"applicationSettings\" type=\"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\"></sectionGroup>"
},
new SPWebConfigModification() { 
    Path = "configuration/configSections/sectionGroup[@name='applicationSettings']",
    Name = "section[@name='MyNamespace.Properties.Settings']",
    // Sequence, Owner, Type
    Value = "<section name=\"MyNamespace.Properties.Settings\" type=\"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" requirePermission=\"false\" />"
},
new SPWebConfigModification() { 
    Path = "configuration",
    Name = "applicationSettings",
    // Sequence, Owner, Type
    Value = "<applicationSettings></applicationSettings>"
},
new SPWebConfigModification() { 
    Path = "configuration/applicationSettings",
    Name = "MyNamespace.Properties.Settings",
    // Sequence, Owner, Type
    Value = "<MyNamespace.Properties.Settings></MyNamespace.Properties.Settings>"
},
new SPWebConfigModification() { 
    Path = "configuration/applicationSettings/MyNamespace.Properties.Settings",
    Name = "setting[@name='SomeSetting']",
    // Sequence, Owner, Type
    Value = "<setting name=\"SomeSetting\" serializeAs=\"String\"><value>SomeValue</value></setting>"
}

Wenn also applicationSettings nicht vorhanden ist, wird es sowohl als sectionGroup als auch im configuration Knoten angelegt. Dann wird unsere applicationSettings section angelegt und unser setting in der section.

Zurückziehen

Die Folgefrage ist nun: Wenn ich meine Lösung zurückziehe und mittlerweile hat eine andere Lösung Änderungen durchgeführt, die im applicationSettings-Knoten liegen, wird dann der applicationSettings-Knoten gelöscht (und damit die Änderungen der anderen Lösung)?

Einige haben diese Befürchtung und setzen deshalb den Owner der übergeordneten Modification auf eine zufällige Guid. Dies ist aber gar nicht nötig:

Wenn beide Lösungen wie im obigen Beispiel aufgebaut sind, also mittels EnsureChildNode einen applicationSettings-Knoten verlangen, dann wird dieser erst gelöscht, wenn beide Lösungen zurückgezogen werden. Solange als SPWebConfigModifications in der WebApplication liegen, die einen applicationSettings-Knoten verlangen, bleibt dieser bestehen. Die Antwort wäre also: Nein, wird er nicht, solange alles richtig implementiert ist.