Manage SPSite and SPWeb programmatically by using Visual Studio 2010

The SharePoint terminology of sites, webs and site collections is a bit confusing at first. An IIS website can contain one SharePoint web application, which can be represented as an instance of the SPWebApplication class. This web application can contain numerous site collections. Programmatically a site collection is an instance of the SPSite class. And finally, each site collection can contain numerous websites (represented as SPWebs), which themselves can contain multiple websites, too.

The hierarchy can be represented as follows:

  • SPWebApplication
    • SPSite
      • SPWeb
        • SPWeb
        • SPWeb
          • SPWeb
        • SPWeb
      • SPWeb
    • SPSite
      • SPWeb

The entry point is usually an SPSite object. You can construct an SPSite from an URL or if your program runs in a SharePoint context, you can leverage the SPContext class to get a reference of the current SPSite. But typically you won’t stop at the SPSite. Most likely you’ll want to work with a website, namely an SPWeb object. It’s fairly easy to acquire an SPWeb once you have an SPSite. SPSite has a method called OpenWeb with multiple overloads. The most noteworthy of these is the parameterless one, which opens the website based on the url you used to open the SPSite. A typical usage looks like this:

using (SPSite site = new SPSite(“http://myspsite.com/myWeb”))
{
using (SPWeb web = site.OpenWeb())
{
//do some stuff here
}
}

Note the using blocks. Both SPSite and SPWeb implements the IDisposable interface, and you should definitely release them to avoid memory leaking. However, if you acquired your SPSite (or SPWeb) instance from a shared resource (e.g. from the SPContext class) then you should not dispose them, since SharePoint will definitely want to use them afterwards, and that will raise an exception.
Subweb creation is not a typical task, but it’s fairly easy using an SPWeb. You just need to call the Add method of the Webs property. It has three overloads, but they are very self explanatory.

Property bag access is very simple, too. Use the AllProperties property of your SPWeb. It’s a simple HashTable, so you can use an object as a key and value, too. There’s one big catch, however. There’s a property on the SPWeb called Properties. This also works with the property bag service, but you should use it only in legacy situations. The main reason is that the Properties collection is case-insensitive (which was good as SharePoint 2007 was concerned) and in SharePoint 2010 property bag access (and the keys) are case-sensitive. Imagine you put a custom property with the key “MyKey”, using the Properties collection. SharePoint will happily create a new property with the key in lowercase, so it’ll be “mykey”. But when you’ll try to access it (using the Properties, or the AllProperties collection) it’ll look for the “MyKey”, and will not found that. So always use the AllProperties collection.

Whenever you make changes to an SPWeb you should call its update method. This will take care of persisting the changes in the database backing up SharePoint. You can use batching too, so it’s not important to call the Update method after every operation (on the contrary, it would decrease performance).

Last but not least: feature activation. You can activate a feature on a site or a web by adding or removing its guid to the Features collection. I don’t think this needs further explanation.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s