Hot answers tagged

14

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


11

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


9

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()) { } } ...


7

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


7

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


6

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


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

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


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


5

It looks like you are writing a server-side object model code in your custom application page that uses SPSite or SPWeb objects but you didn't dispose these objects and this is cause wasting system resources. so try to dispose these objects to release its allocated memory as the following: To dispose SPWeb object, it's preferred to use Using statement as ...


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

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

According to the Bible of SharePoint IDisposable objects, Best Practices: Using Disposable Windows SharePoint Services Objects: SPWeb.ParentWeb Property Updated Guidance 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 ...


4

No, you should not use a using as you're not instantiating the object - you're getting a reference to an existing object. Let the event receiver handle the life cycle of its own objects.


4

Typically disposing isn't much of an issue. If you've got a large farm and are doing a lot of looping you may want to consider disposing after you complete your task for that site/web. The reason it's not much of an issue is because the objects just hold up memory when the PowerShell app is running. Once you close out of PowerShell, the memory those sites/...


3

There is no need to dispose of objects in the managed client object model, as there are no unmanaged resources in use, everything is cleaned up by the garbage collector.


3

As Hugh said, in the getSelectedList function you have the first error. using (myWeb) { SPListCollection myLists = myWeb.Lists; foreach (SPList myList in myLists) { if (myList.Title.Equals(ListTitle)) rList = myList; } } myWeb.Dispose(); This will dispose the myWeb istance after the using block. The suggested way from ...


3

I would strongly recommend you go through this reference article if you haven't done so already.


3

The code you written is Ok. using statement will dispose the SPWeb object you have instantiated. Parent Site - This object is not initiantiated by you, you are using SPSite that belongs to SPContext. SPContext objects are managed by the SharePoint framework and should not be explicitly disposed in your code. This is true also for the SPSite and SPWeb ...


2

You would need to share with us the piece where you get a reference to the WEB and Library, related to the Best practices SPWEb/SPSite dispose (e.g. try putting the whole thing into a using {}, make sure you do not dispose SPContext.Current.Web, etc.) As best practice, try checking if library has Content types enabled (ContentTypesEnabled property), then if ...


2

You can use this tool to check if you need to dispose any object or not SP Dispose Checker


2

If you want to understand disposing better, then you can create yourself a memory leak. Instantiate an object inside a function and call that function 10 times every 2 seconds for 100 seconds, and watch your applications memory. An object that leaves residue behind will increase the memory of the application gradually. Best practice is on that post, if an ...


2

In this post you can find this: 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. Also you can find this note: This best practice addresses the issue identified by the ...


2

In the first example there is no problem in disposing the SPWeb, because you're sure nobody is going to use it later. In the second example you run the risk of a memory leak or a crash if there is any event receiver with a higher sequence on the same list/content type. The other event receiver will probably try to use the Web which has been disposed, ...


2

The only real 'danger' is that you will cause the API to re-fetch the metadata for that object. Depending on your code, your context and the SPWeb/SPSite objects, this can potentially be a large performance hit and therefore a significant flaw. You will not cause exceptions or hard errors by disposing too early or too late, it's only messing up SharePoint ...


2

In general, you should only dispose an object that you are created. using (SPSite site = new SPSite(@"http://sitecollection/")) { SPWeb web = site.RootWeb; } In example 1, the instantiator is you. Doesnt matter if you call dispose in the middle of your code (as long as the object is not needed anymore) or wait until it dispose ...


2

If an IDisposable SharePoint object is passed into a function, does an explicit Dispose() call need to made on it? No. Generally, whoever created the object is also responsible for disposing of it. In your example, TheCallingFunction might have had some other use for the web after DoSomethingRad returns. See also this StackOverflow question. Most of the ...


2

From this sample on msdn, I would said that dispose is still required. using (SPSite oSiteCollection = new SPSite("http://Site_Name")) { SPWeb oWebsite = oSiteCollection.AllWebs["DeleteWebSite"]; oWebsite.Delete(); oWebsite.Dispose(); } I also had a check at the source for the Delete method. All I see is a call to SPRequest.Delete(string) by ...


2

According to this example on MSDN, they have disposed the SPWeb object after deleting it. After using ILSpy on the SPWeb.Delete() method, we can see that internally it calls the Microsoft.SharePoint.Library.SPRequest.DeleteWeb(string bstrUrl, bool bRecycle) method. So from this we can infer that SPWeb.Delete() must be synonymous with deleting a site from ...


2

I can't see a place where you leave an open web opened - the risk is higher resource usage for a longer time, if you dispose properly you would need less resources. If this event receiver is not used frequently, I would ignore it.


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