Tag Info

Hot answers tagged

31

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 ...


11

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")) ...


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 ...


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

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 ...


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

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 ...


3

After some research I found the answer on the general description page of the IDisposable-interface. If an object's Dispose method is called more than once, the object must ignore all calls after the first one. So, if you accidently dispose an SharePoint-object twice, no harm done.


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

I think you have to dispose the SPWeb objects when retrieved from the SPSite.AllWebs collection. If you have look at the implementation of the SPWebCollection class by decompiling it, you can see that everytime a SPWeb is returned, it is instantiated by calling OpenWeb on the SPWebCollection.ISPWebCollectionProvider (which is in this case the SPSite). Thus, ...


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.


3

Counting the contents of the item collection can be very slow. Instead use the ItemCount property on the list. With regards to checking for leaks, have a look at SPDisposeCheck.


3

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 ...


3

The warning "Potentiallt excessive number of SPRequest objects.." you get in ULS log could be or could not be an issue. This warning does not necessarily indicate your objects are not being disposed, just that you have opened alot of them (like when doing a loop through current webs). This warning can be mitigated by setting up the treshold to a larger ...


3

I would strongly recommend you go through this reference article if you haven't done so already http://msdn.microsoft.com/en-us/library/aa973248(v=office.12).aspx#sharepointobjmodel__spwebobjects


3

There is no need to dispose of objects using the Client Object Model with JavaScript because it handles the memory management for you. For more information on JavaScript memory management check out this article: https://developer.mozilla.org/en-US/docs/JavaScript/Memory_Management



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