Lars Nielsen's Discoveries

February 20, 2010

Using SPWebModification to modify the web.config (Part 3)

Filed under: Development,SharePoint — Lars Nielsen @ 9:06 pm
Tags: ,

This is one of a series of posts – start here to read the whole series

AttributeConfigModification class

Now I’ll look at the class AttributeConfigModification, which models a change to an attribute in the web.config file.  This class inherits from an abstract base class, ConfigModification, which actually does most of the hard work.  So you’ll see that AttributeConfigModification is pretty basic.  All it has are 2 string type properties called AttributeName and AttributeValue.  There’s a constructor, and then implementations of the abstract methods in the base class:


public AttributeConfigModification(string changesOwner, string xpathLocation)
: base(changesOwner, SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute, xpathLocation)
{ }

public override string GetModificationName()
{
return AttributeName;
}

public override string GetModificationValue()
{
return AttributeValue;
}

Notice that the constructor calls the base class using EnsureAttribute – this is going to tell SharePoint that we’re dealing with the a change to an attribute of an existing XML element.  Remember what we want to do is to change 3 attributes in the proxy element: usesystemdefault, proxyaddress and bypassonlocal.  So for example, to represent an attribute:


bypassonlocal = "true"

You do this:


AttributeConfigModification mod;
mod.AttributeName = "bypassonlocal";
mode.AttributeValue = "true";

And that’s all there is to this class.  As I said, all the real work goes on in the base class which I’ll describe in the next post.

Before that though I’ll mention another class you can see if you look again at the class hierarchy:

Class Diagram

ElementConfigModification

The ElementConfigModification class also implements the abstract ConfigModification base class.  Whereas AttributeConfigModification represents a single attribute in XML, ElementConfigModification represents (you guessed it) a whole element.  So you might use ElementConfigModification to add (say) a new connection string to the web.config file, like this:


<add name="myconnectionstring" value="Data Source=server;Initial Catalog=db" />

The element is represented as an ElementName (which would be set to “add” in this case) and a list of Attributes (there would be 2 attributes in this case: name=”myconnectionstring” and value=”Data Source=server;Initial Catalog=db”).  In this project we don’t actually use ElementConfigModification so I won’t go over all the source code in detail.  I’ve included it to show how it shares functionality via the common base class.

Compare the constructor of ElementConfigModification with that of AttributeConfigModification:


protected ElementConfigModification(string owner, string xpathLocation)
: base(owner, SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode, xpathLocation)
{ }

They’re nearly the same, the only difference is the call to the base class constructor is passing EnsureChildNode rather than EnsureAttribute.  That will tell SharePoint that we’re asking it to add a whole new element, not just change the attributes.

As well as ElementConfigModification and AttributeConfigModification I’ll eventually need to create a class SectionConfigModification which will ensure that the section of the web.config is there and create it if necessary.  SharePoint throws an error back if you try to create a new XML element at a path that doesn’t already exist in the web.config.  You need to create the section first, then create the element within the section.  Here’s a a great explanation of this issue.

Remember the XML fragment in the web.config in part 1:


<system.net>
<defaultProxy>
<proxy autoDetect="True" />
</defaultProxy>
</system.net>

The sections here are sections system.net and defaultProxy.  They’re already in the web.config file anyway so I don’t need to create them.  If I did need to create them, I’d create a SectionConfigModification class to do it.  The constructor of the SectionConfigModification class would pass EnsureSection to the base class like this:


protected SectionConfigModification(string owner, string xpathLocation)
: base(owner, SPWebConfigModification.SPWebConfigModificationType.EnsureSection, xpathLocation)
{ }

The rest of the class, I’ll fill in at some point when I need it.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Create a free website or blog at WordPress.com.

%d bloggers like this: