I guess when MS experts decided to publish this article , they kind of solved many questions in people’s head with regards to dispose patterns that one should follow when developing against SharePoint object model. Although , I respectfully disagreed with two things mentioned in that article (such as disposing RootWeb object or not putting Response.Redirect() in the finally block as I stated here a long time ago) , this article has been always my first-to-check kind of reference when I have any disposal related questions. It was a great move. Later on , Roger Lamb started to maintain a fantastic list of Dispose rules here which was again another great help to the developer community. What’s great about Roger’s post is that he keeps updating it which makes it even more attractive to follow.
Admittedly, with all the efforts put towards this so far, there are still a few edge cases that are not clear when it comes to hygienic disposal of our objects . I am hoping that Microsoft’s top subject matter experts can shed some light on them. For example – I have done some research on whether I should call Dispose() on SPWeb or SPSite objects returned by properties objects or those objects are automatically disposed by the reference code. I was particularly interested in the following three scenarios:
Ā Provisioning Handler:
[CSharp]
public class InfraStructureProvisioningEngine : SPWebProvisioningProvider
{
public override void Provision(SPWebProvisioningProperties props)
{
//Does the following reference to SPWeb leak?
SPWeb web = props.Web;
//Omitted code for brevity
}
}
[/CSharp]
Event Handler:
[CSharp]
public class UserPictureListEventHandler : SPItemEventReceiver
{
public override void ItemUpdated(SPItemEventProperties properties)
{
//Does the following reference to SPWeb leak?
SPWeb webNonelevated = properties.OpenWeb();
// Omitted code for brevity
}
}
[/CSharp]
Feature Receiver :
[CSharp]
public class ODSSParticipateFeatureReceiver : SPFeatureReceiver
{
public ODSSParticipateFeatureReceiver() { }
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
//Does the following reference to SPSite leak?
SPSite site = properties.Feature.Parent as SPSite;
// Omitted code for brevity
}
}
[/CSharp]
Reflecting into MS code didn’t help as those places in which I could potentially find the answer, were mostly obfuscated and reading the IL didn’t reveal anything either š
Based on my research some of them dispose and some do not as they may be somehow bound to SPContext object! There are quite a few places where properties object is created and returned to the caller , so I am like , okay, under what situations I need to dispose then? Honestly , in a feature receiver that barely gets activated or deactivated , properties leakage might not be a biggie , but in an event handler on a busy list ,this can cause the memory footprint of your application grow which is definitely not a good thing!
Last Friday , I finally got a chance to exchange couple emails with Roger Lamb and ask him my questions. His comment is that he is still researching on this particular case and he’ll get back to me (FWIW, to all of us!) by a blog post in the following weeks. All I can say is that I am really looking forward to see what Roger will come up in his blog post. Keep an eye on his blog if you’re interested in this topic.
Now that we are into disposing stuff, let me share another thing with you.We know for sure that disposing the SPWeb object returned from the call to SPContext.Current.Web and the SPSite object returned from the call SPContext.Current.Site is a big NO NO , right? but what about disposing oSite object in the following code snippet?
[CSharp]
SPWeb oWeb = SPContext.Current.Web;
SPSite oSite = oWeb.Site;
[/CSharp]
just be aware that objects hanging off of SPContext , no matter how many levels deep it gets, SHOULD NOT be disposed and does not require any action. Another thanks to Roger for confirming this one for me again!
