Tag Info

Hot answers tagged

32

You would never use RootWeb in the context of a using statement and OpenWeb() isn't useful unless the URL specified in the SPSite constructor was a sub web of the site collection in lieu of just the site collection URL. So, you should never do this: using (SPWeb web = site.RootWeb) { // do something with web } ...and OpenWeb() is useful in a scenario ...


21

James and Toni are absolutely correct but have missed the obvious IMHO - your code has a deeper flaw and if you fixed this then disposing the objects is not required. You should (where possible) use the SPWeb and SPSite objects from SPContext - they are already created for you by the SharePoint web part infrastructure and its more efficient to use these ...


12

In SharePoint 2007 you need to dispose the returned SPWeb if you use properties.OpenWeb() In SP2010 you should use the SPItemEventProperties.Web property instead. This performs better than OpenWeb and has no dispose issues. hth Anders Rask


11

Yes, you will need to dispose SPWebs created through SPSite.OpenWeb(). To dispose of it, simple call web.Dispose() when you're done in the method. You could also use the Using statement to the same effect, without needing to directly call Dispose() Using site As New SPSite(SPContext.Current.Web.Url) Using web As SPWeb = site.OpenWeb() ...


10

Use of objects, such as SPWeb or SPSite, in PowerShell requires a proper memory management. Get commands dispose of these objects immediately after the pipeline finishes, but by using SPAssignment, you can assign the list of objects to a variable and dispose of the objects after they are no longer needed. Here is an example of usage of SPAssignment object, ...


8

The key is if your code creates an instance of an SPSite or SPWeb you must dispose of it. However, if you use an instance from SPContext.Current you should not dispose of it. i.e. Dispose of what you create, whether that is directly or indirectly. Example of creating your own instance, so using is required: using(SPSite site = new SPSite("http://server")) ...


7

+1 James You should also try to use SharePoint Dispose Checker tool in your projects to analyze your code for potential memory leaks and to apply best practices.


7

In first case SPWeb web = site.RootWeb; SPWeb does not need to be disposed as SPWeb is retrieved from RootWeb. However, in second case SPWeb needs to be explicitly disposed. Mere disposal of SPSite is not enough. So the code should look like: using (SPSite site = new SPSite(SPContext.Current.Web.Url)) { using (SPWeb web = site.OpenWeb()) { } } ...


6

I could be mistaken but I think he's referring to the creation of SPWeb objects when going through the allwebs enumeration. foreach(SPWeb web in SPContext.Current.Site.AllWebs) { try { //do something... } finally { web.dispose(); } } In this case I would dispose of the objects created but not this object: ...


6

You should review your code and properly dispose the SPSite, SPWeb (and others) you create yourself (as in "new SPObject(url)" and sites.OpenWeb()). These objects contains unmanaged SPRequest objects that will not automatically be disposed. To assis you in this process you should use SPDisposeCheck (i usually set SPDisposeCheck to run automatically when i ...


6

That code will dispose the SPWeb object correctly with the using statement. If an exception is thrown in the method, it will still get disposed.


5

I recommend installing and running this tool to check whether you are disposing your objects correctly: SPDisposeCheck


5

Nope, you're definitely right in what you say. Although Roger Lamb's post didn't seem to get updated with this, Stefan talked about it here over a year ago: Whenever an SPWeb object is created the SPSite object associated with the new SPWeb object automatically adds the new SPWeb object to an internal list. This works for all SPWeb object creations - be ...


5

A memory leak will manifest itself in whatever is the host process for the code which has the leak. In the case of SharePoint code, this won't be the SQL process - most likely what you're seeing here is simply down to the fact that SQL generally consumes as much memory as it can (i.e. whatever isn't being scavenged/used by other processes). You can peg it ...


5

I'm guessing that you are using a regular PowerShell session, probably with the SharePoint snapp-in loaded. And not the 'SharePoint Management Shell'. With a regular powershell session each command is executed with-in its own thread. And disposable objects, like SPWeb, are automatically disposed on the end of a thread. Thus what could happen is that the ...


5

No, you don't need to dispose the properties, neither you need to dispose the SPWeb or SPSite object, returned using SPItemEventProperties.ListItem Reason: The SPItemEventProperties class internally implements the Dispose() method itself. How: Let's have a look at the source code of the SPItemEventproperties class using the Reflector, to make sure we are ...


5

No your code isn't leak safe. It'll leak all of the SPSites and SPWebs You need to add a dispose of each SPWeb and SPSite like this: SPSiteCollection siteCollection = webApp.Sites; foreach (SPSite site in siteCollection) { SPWebCollection webCollection = site.AllWebs; foreach (SPWeb web in webCollection) { SPFeature feature = ...


5

Just to clarify on what you said with that statment, An earlier version of this article recommended that the calling application should dispose of the SPWeb.ParentWeb. This is no longer the official guidance. The dispose cleanup is handled automatically by the SharePoint framework. to my understanding: from where you start the spweb object ...


4

No, you don't need to dispose objects hanging off an SPContext obtained this way. If you look in Reflector, you'll notice SPContext.Current runs this code internally - effectively they do the same thing (which is to deserialize the context information which SharePoint stores in HttpContext.Current.Items).


4

Someone might need to back up me, but if you're getting an object from that collection, it does actually create an SPWeb instance each time (the collection is just a collection of object references rather than the objects themselves?), so you will indeed need to dispose of the object after each iteration.


4

The rule is complicated, but in a nutshell, you should dispose of any object that you create yourself that implements the IDisposable interface. In the context of SharePoint, this includes: Any SPSite object you create using siteColl.OpenWeb(), returned by SPSiteCollection.Add, by the SPSiteCollection[] index operator, or yielded in a SPSiteCollection ...


4

SPList objects cannot be disposed.


4

Yes, this code leads to memory leak. I prefer to use this (or this one for 2007 sharepoint) page every time, when I doubt if object should be disposed. According section SPSiteCollection [ ] Index Operator you must dispose SPSite object. So, in order to correct dispose SPSite in your example, you need to use this code: using (var mySite = ...


4

Based on the warning you are experiencing, the SPDisposeCheck tool should refer to the following code block: using (SPSite RootSite = new SPSite(WebAppUrl)) { SPWeb RootWeb = RootSite.RootWeb; // CUT ... } Statement: RootWeb := RootSite.{Microsoft.SharePoint.SPSite}get_RootWeb() It would seem that the tool is suggesting that you ...


4

No. If you do, you might actually get an error, because the using statement under "TheCallingFunction" would call dispose on "web" after "DoSomethingRad" already called "Dispose()". As a rule of thumb, you have to look at your public method as a black box that just does what you expect it to do. To follow the Single-Responsibility Principle just do ...


4

It got nothing to do with database, when you create a new object it reserves some space or memory in RAM. It is per object, for example when you use SPSite site = new SPSite(URL);it creates a object SPSite in memory. There was a scenario when I had to go through hundred of sub-webs of a site collection and I forgot to dispose SPWeb and it crashed ...


4

Yes, SPSite needs to be disposed But you can handle the disposal of SPSite through the enumerator using the extension method (see below): static class Extensions { public static IEnumerable<SPSite> AsSafelyDisposed(this SPSiteCollection sites) { foreach (SPSite site in sites) { try ...


4

When you close the PowerShell.exe process, the memory is freed. If you need to dispose objects to keep memory pressure down (important in production environments or if you're looping over all sites/webs), make sure to dispose. If not, you don't need to worry about disposing. The reason why we're so crazy about disposing in the first place is ...


3

There is a best practices guide from microsoft about when to dispose which objects (SPSite, SPWeb): http://msdn.microsoft.com/en-us/library/ee557362(v=office.14).aspx Also there is a dispose checker tool provided by microsoft: http://archive.msdn.microsoft.com/SPDisposeCheck


3

It won't cause a memory leak but it's not best practice. Some API calls require SharePoint to have parent SPWeb and SPSite objects initialised. Accessing the list once its parent web object has been closed could cause errors (perhaps not in this exact code). My opinion is to play it safe and don't risk it.



Only top voted, non community-wiki answers of a minimum length are eligible