Disposing SharePoint objects - what they don't tell you

If you're a SharePoint developer and find yourself regularly writing code to work with SPListItem objects, here's some info which might help you factor your code in a slightly neater way in some scenarios.  Interestingly this doesn't get mentioned in any of the key papers/articles - I can think of a good reason for this (which we'll look at), but in my mind this is a safe technique. If you have other ideas however, I'd love to hear from you.

Most developers are now fairly well-versed in the techniques needed to write efficient SharePoint code (key resources are listed at the end of the article), specifically in terms of disposing of any SPSite/SPWeb objects your code creates. The thing is, having to always be mindful of disposing these objects can sometimes restrict us in the way we want to write our code - consider the following simplified example:

public void DoSomething()
{
    SPList list = getList();

    // do something with list..
    foreach (SPListItem item in list.Items)
    {
        processItem(item);
    }

    // ** PROBLEM - how do we now dispose of the SPSite/SPWeb objects we created earlier? **
}

private SPList getList()
{
    // can't dispose of these objects here if we're returning a list - we'll be attempting to use 
    // objects which have already been disposed of..
    SPSite site = new SPSite("http://cob.blog.dev");
    SPWeb web = site.OpenWeb("/MyWeb");
    SPList list = web.Lists["MyList"];

    return list;
}

The problem here is we created our SPSite/SPWeb objects in a different method to where we need to dispose them - this can happen a lot when writing library code. To extend this example, here's a pattern I regularly use to ensure I'm getting my objects the most efficient way - using SPContext if it's present, but instantiating them myself if it isn't (i.e. the code is called from an event receiver, console app etc.):

public void DoSomething()
{
    bool bDisposalsRequired = false;

    // get list from SPContext if we have one..
    SPList list = getListFromContext();
    if (list == null)
    {
        // otherwise get list from objects we create..
        list = getInstantiatedList();
        bDisposalsRequired = true;
    }
    
    // do something with list..
    foreach (SPListItem item in list.Items)
    {
        processItem(item);
    }

    if (bDisposalsRequired)
    {
        // ** PROBLEM - how do we now dispose of the SPSite/SPWeb objects we created earlier? **
    }
}

private SPList getInstantiatedList()
{
    // can't dispose of these objects here if we're returning a list - we'll be attempting to use 
    // objects which have already been disposed of..
    SPSite site = new SPSite("http://cob.blog.dev");
    SPWeb web = site.OpenWeb("/MyWeb");
    SPList list = web.Lists["MyList"];

    return list;
}

private SPList getListFromContext()
{
    SPContext currentContext = SPContext.Current;
    SPList list = null;

    if (currentContext != null)
    {
        list = currentContext.Site.AllWebs["MyWeb"].Lists["MyList"];
    }

    return list;
}

When the code starts to become more complex like this, we start to really want a simple way of disposing the objects we created elsewhere. I'd probably caution against this, but what happens if you created the SPSite/SPWeb objects not only in another method, but another class? All of a sudden disposing of objects correctly is a lot more complex than the examples given in the white papers. 

Now, the savvy SharePoint developer might think "Hold on, the SPList has a ParentWeb object (and SPListItem has a ParentList object!), what happens if I go up the hierarchy and dispose that way?" - code to this would look like:

if (bDisposalsRequired)
{
    list.ParentWeb.Dispose();
    list.ParentWeb.Site.Dispose();
}

Now how would we know the correct objects have been disposed? Are these objects the same objects we were using earlier? Or has SharePoint populated these properties with references to different objects, meaning we've left our original objects alive and could run into scalability problems?

Well, the good news is these are the same objects, so disposing in this way will dispose of the objects you created. We can tell this by comparing the objects using System.Object's GetHashCode() method:

private void compareObjects()
{
    SPSite site = new SPSite("http://cob.blog.dev");
    SPWeb web = site.OpenWeb("/MyWeb");
    SPList list = web.Lists["MyList"];
    
    SPWeb parentWeb = list.ParentWeb;
    


    // no message displayed..
    Debug.Assert(parentWeb.GetHashCode() != web.GetHashCode(), "Objects are not same!");
    

    // create a *new* SPWeb object and compare it to our other reference..
    web = site.OpenWeb("/MyWeb");

    // message IS displayed..
    Debug.Assert(parentWeb.GetHashCode() != web.GetHashCode(), "Objects are not same!");
}

What we see from this is that the SPWeb object stored in the list.ParentWeb property has the same hash code as the original SPWeb object we created, but if we create a new instance of the same web, it has a different hash code. This indicates the objects in the first comparison are the same - so disposing of them through the ParentWeb reference will indeed dispose of the objects we created. So happy days - we've found we can factor our code in a way which may be more logical and readable.

The caveat

So why might this not be mentioned in any of the published guidance? Well, before using this technique throughout your code you should consider that in writing code in this way we are effectively relying on an internal implementation detail of the current SharePoint API. If Microsoft were to change this in a service pack (or the next version of SharePoint), our code may no longer dispose of objects correctly. I'd recommend giving this your own consideration (not least because you might conclude differently to me), but I'd suggest this change would be fairly unlikely. The reason for this is the SharePoint team themselves need to eliminate any unnecessary SPSite/SPWeb objects, so of course it makes sense that the the same SPWeb instance used to obtain the SPList is used to populate the ParentWeb variable. Creating an extra instance would make the API less efficient. On that basis, I personally am happy to write code in this way. If you think I've got this wrong (I can't guarantee I haven't), of course I'd love to hear from you.

In an upcoming article, I'll also discuss the idea of going beyond the MSDN examples, and trying to write SharePoint data access code in a more 'enterprise' or 'patterns' kind of way. Stay tuned for more on this.

Disposing SharePoint objects - required reading

• Best Practices: Using Disposable Windows SharePoint Services Objects


• Best Practices: Common Coding Issues When Using the Shareoint Object Model