15

Why do some SharePoint examples use

using (SPSite site = new SPSite(SPContext.Current.Web.Url))
{
    ...
}

and not just simply?

SPSite site = SPContext.Current.Web.Site;
...

Update

I think I have narrowed the question down to the following:

It seems that I should not use SPContent.Current directly, unless I am certain, that my code runs inside SharePoint. But when would that not be true?

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
Jan Aagaard
  • 10,940
  • 8
  • 45
  • 80
  • 1
    Take a look at a similar question from me: http://sharepoint.stackexchange.com/questions/20192/using-spcontext-current-or-using-static-url – Dennis G Nov 08 '11 at 15:01
  • 1
    On bigger projects you sometimes have external utilities not running in SharePoint. Another example are unit tests which also don't run in SharePoint. If you are simply developing visual webparts and don't unit test - your code runs in SP. – Dennis G Nov 08 '11 at 15:18
  • when frequently used in code there seems to be a performance issue with the new SPSite/SPWeb approach – dc2009 Sep 11 '12 at 14:04
  • @moontear I was wondering: if I'm programming an HttpModule - is that running _in_ SharePoint? It would be part of the request and all, but it's kinda more at the IIS/Web Application level - just interested in your opinion/observation/etc – Code Jockey Nov 08 '13 at 19:15
  • You should be commenting on my answer then and not the original post ;-) - As SharePoint is interfering with the IIS request pipeline I'm not sure if SPContext would even work, it is definitely safer to create your own SPSite. In all "external" cases you can't be sure you have a proper SPContext (e.g. features, when you activate them via PowerShell you doN't have a context!), go with the manual route. If you can't be sure how your HttpModule is executed... you know what to do. – Dennis G Nov 09 '13 at 12:21

3 Answers3

11

Take a look at the best practices documentation on disposing objects in SharePoint 2010 from Microsoft, however there are opposing views.

There are a few key takeaways for SharePoint projects:

  • Always dispose your SPWeb / SPSite objects --> memory leaks
  • Make use of SPContext.Current... when you are sure your code is running in a SharePoint context
    • Unit Tests mean no Sharepoint context
    • External utilities mean no Sharepoint context
    • Powershell means no SharePoint context (e.g. activating a feature with feature receiver might fail)
  • Do not dispose SPContext.Current... but create your own object (again using)

You might have problems with consistency with your multiple SP.. objects.

In the end SPSite site = SPContext.Current.Web.Site; is fine in some instances, but you do not have control over this site object - that might be the problem. If you go for new SPSite(...) you will always have your SPSite and not something SharePoint created and managed for you.

Personally I almost always go for the using structure so all objects are disposed properly afterwards. Alternatively I use SPContext.Current.Web without disposing.

Community
  • 1
  • 1
Dennis G
  • 21,405
  • 19
  • 96
  • 133
4

It depends on the context in which your code runs. For instance, you need to create a new SPSite instance if you are running within a RunWithElevatedPrivileges block.

Nemanja Trifunovic
  • 24,346
  • 3
  • 50
  • 88
0

Dennis G is correct. Disposing the SPSite/SPWeb/etc is important but make sure you do not dispose the objects that are provided to you by the API directly. It's subtle but critical otherwise your response will never get generated or cause even thread abort situations. In my experience, if I need quick information on the SPSite or SPWeb property that I am sure available to the user context (either a content manager authorized user or anonymous), then using SPContext.Current.* object is great. Otherwise, use the RunWithElevatedPriveleges method to wrap your code and inside that lambda has the following pattern:

SPSecurity.RunWithElevatedPrivileges(() =>
{
  using (SPSite site = new SPSite(SPContext.Current.Site.ID))
  {
    using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))
    {
     // stuff goes here elevated
    }
  }
});
Roman
  • 1,177
  • 1
  • 17
  • 25