So, after about two hours on the subject I am thoroughly confused. There are viewpoints all over the place on how, when, and why to use Dispose() on SPWeb objects as they relate to SPContext.

Can someone clear this up for me in a specific context? I am creating a Site Definition that instantiates lists, so assume that I can ALWAYS pull the lists from SPContext. There is never a danger of a console or powershell execution.

The rule seems to be, never, ever, ever dispose of the SPContext.Current.Web object. Does that rule also apply to mirror instances? Meaning:

using (SPWeb web = SPContext.Current.Web)
    SPList TargetList = web.GetList(web.ServerRelativeUrl + "/lists/Post");
    SPListItemCollection items = TargetList.GetItems(query);


SPList TargetList = SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Post");
SPListItemCollection items = TargetList.GetItems(query);

Is there a real, qualitative difference here? Do I not save a process cycle by NOT instantiating a new object, which really just serves as a placeholder?

Would there be danger in writing a data access object like this?

public static SPList PostList()
  return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Post");
static public List<Post> GetPostsByCommunity(string CommunityName) 
    SPList TargetList = PostList();
    SPListItemCollection items = TargetList.GetItems(query);

Since the lists I am working with are a small collection of 4, I could have static objects for each, and then have very tight and simple Data Access methods which return Objects populated by the returned information.

(Ignoring the lack of query and looping. I want to focus purely on the data access)

Tell me why this is a bad idea and what is the right way to do this.

1 Answer 1


You are correct, never dispose an object retrieved from a Property from SPContext.

The simple reason being, you can never be sure that there is another thread, control or other piece of code that executes after your code does and is expecting that properly to exist.

Your first two examples (where you put one versus the other) are functionally identical, except you dispose of the Web property of SPContext.Current in the second, which is ill-advised.

  • How about the data access model. Is this advisable?
    – Wesley
    Commented Jun 30, 2012 at 21:55
  • Generally yes, with that syntax, but I can't quite tell what pattern you're going for so it's difficult to tell in the wider context - for example you're just using static over instance methods, you would want to check to make sure the current session context is valid, that the current user has permissions, etcetc, and you'd do that in perhaps a singleton or factory pattern.
    – James Love
    Commented Jun 30, 2012 at 22:00
  • SPContext.Current already knows how to track and manage which is the right SPWeb for the current calling context. So, let it handle it. However, create a general rule if you didn't create the IDisposable object - it was handed to you - then don't dispose it. Commented Jun 30, 2012 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.