Odd behavior when working with SharePoint’s SPWebConfigModification

I’m currently working on a SharePoint development project and I’ve run into something that I didn’t think was obvious.  (That’s my nice way of saying that I was hitting my head against the wall for four hours trying to figure this out!)

I’m putting together a SharePoint Feature that will add two connection strings to the web.config.  My original code was something like this:

private void AddConnectionString(SPWebApplication webApp, string Owner, string connectionName, string connectionString, uint Sequence)
{

    // This is the snippet to add to the web.config
    //  <connectionStrings>
    //    <add name="cnName" connectionString="LDAP://myCompany.local/DC=myCompany,DC=local" />
    //  </connectionStrings>

    SPWebConfigModification addChild = new SPWebConfigModification();
    addChild.Name = connectionName;
    addChild.Path = "configuration/connectionStrings";
    addChild.Owner = Owner;
    addChild.Sequence = Sequence;
    addChild.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
    addChild.Value = String.Format("<add />");
    webApp.WebConfigModifications.Add(addChild);

    SPWebConfigModification nameAttribute = new SPWebConfigModification("name", "configuration/connectionStrings/add"); 
    nameAttribute.Owner = Owner; 
    nameAttribute.Sequence = Sequence; 
    nameAttribute.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute; 
    nameAttribute.Value = connectionName;

    webApp.WebConfigModifications.Add(nameAttribute);

    SPWebConfigModification connectionstringAttribute = new SPWebConfigModification( "connectionString", "configuration/connectionStrings/add"); 
    connectionstringAttribute.Owner = Owner; 
    connectionstringAttribute.Sequence = Sequence; 
    connectionstringAttribute.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute; 
    connectionstringAttribute.Value = connectionString;

    webApp.WebConfigModifications.Add(connectionstringAttribute);

   //Save changes….
}

Since I needed to actually add two connection strings to the web.config, I was running this method twice, with different values.  It would execute fine, but the web.config would only have the last values saved?!  I added the “addChild.Name = connectionName;” line and then I started getting one complete line and one line that was only “<add />”.

SO, I created another copy of this method and changed the names of the attributes, by adding a “2” to them.  When I ran it this time, I got one “<add />” line and the second one had both sets of attributes!

In order to get it to work, I did this:

private void AddConnectionString(SPWebApplication webApp, string Owner, string connectionName, string connectionString, uint Sequence)
{
    //  <connectionStrings>
    //    <add name="cnName" connectionString="LDAP://myCompany.local/DC=myCompany,DC=local" />
    //  </connectionStrings>

    SPWebConfigModification addChild = new SPWebConfigModification();
    addChild.Name = connectionName;
    addChild.Path = "configuration/connectionStrings";
    addChild.Owner = Owner;
    addChild.Sequence = Sequence;
    addChild.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
    addChild.Value = String.Format("<add name=\"{0}\" connectionString=\"{1}\" />", connectionName, connectionString);
    webApp.WebConfigModifications.Add(addChild);

    // Save changes…
}

There are two key lines to making this work.  The first one sets the SPWebConfigModification.Name to a unique value.  The second line sets the entire tag, element and attributes.  I tried changing the “Name” value for the attributes, but the Name value is the actual name of the attribute, so I couldn’t change that or ASP.NET wouldn’t understand it.

Since it was only an element with two attributes, this was relatively straight forward.  If I had to do this to add something like a membership provider, it would have been a lot messier.

I am using this with WSS 3.0 (SharePoint 2007), but I’m assuming that the same behavior is in MOSS 2007.  If anyone has a better explanation of why this works the way it does, please leave a comment.

Print | posted @ Wednesday, February 11, 2009 10:23 PM