SPDisposeCheck on SPLimitedWebPartManager ImportWebPart method

Question

(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)
                Try

                    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)

                Finally
                    webPartCollectionDocReunion.Web.Dispose()
                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

Answer 1

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.

Paul.

Answer 2

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