SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer
How about the data access model. Is this advisable? – Wesley Jun 30 '12 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 Jun 30 '12 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. – Falak Mahmood Jun 30 '12 at 23:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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