(This question is related to MOSS 2007. Might also apply to Sharepoint 2010)

I have run SPDisposeCheck v1.3.1 to detect memory leaks in a solution. There is one issue found that I can't seem to resolve. This might be a "false positive". The following code report the error.

Dim page As SPFile = Sitew.GetFile("Source_Folder_Name/Source_Page")
Dim oWebPart As System.Web.UI.WebControls.WebParts.WebPart = Nothing

    Using webPartCollectionDocReunion As SPLimitedWebPartManager = page.GetLimitedWebPartManager(UI.WebControls.WebParts.PersonalizationScope.Shared)

                    Dim oReader As New System.IO.StringReader("<webParts><webPart>...</webPart></webParts>")
                    Dim oXmlReader As New XmlTextReader(oReader)

                    oWebPart = webPartCollectionDocReunion.ImportWebPart(oXmlReader, "")
                    webPartCollectionDocReunion.AddWebPart(oWebPart, "Main", 0)

                End Try
    End Using

The error occurs with the line : oWebPart = webPartCollectionDocReunion.ImportWebPart(oXmlReader, ""). If I comment this line no error is reported. If I change the line to: oWebPart = webPartCollectionDocReunion.WebParts(0), no error is reported.

The issue seems to be related to ImportWebPart. Anyone seen this error reported?

Thanks, Christian

2 Answers 2


My gut instinct would be that the dispose checker is right in this case. When you use the ImportWebPart() method you're creating a new instance in memory of a WebPart.

When you use the call to the collection via the indexer, would you be taking a reference to the object already in memory, therefore no need to call dispose on it.


  • I have tried doing a oWebPart.Dispose() but I get the same result. Also, here's the error that SPDisposeCheck give me: Statement: local<4726> := webPartCollectionDocReunion Notes: Dispose/Close was not called on SPLimitedWebPartManager.Web
    – user2520
    Commented Feb 25, 2011 at 18:03
  • Hmm it certainly looks like you're calling the dispose on that web in your finally block, so I don't really understand why dispose check doesn't like it. Hopefully someone else may have a view on it.
    – Cimares
    Commented Mar 2, 2011 at 14:25
  • Remember that SPDisposeCheck is not foolproof. It is just pointing you toward suspect code - it will give false positives and will not catch everything. It is up to you to decide if the code is right or wrong.
    – SPDoctor
    Commented Aug 9, 2011 at 9:54

This to me sounds like a false positive. Basically the rule of thumb for disposing SharePoint objects is: if you created it, you dispose it. The manager's Web property looks to me to be created by the SharePoint APPi itself, so you'd expect not to have to dispose of it. Might be interesting to use reflector and inspect the underlying method / class to see if the object gets disposed or not by the API itself..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.