Stefan Goßner

Senior Escalation Engineer for SharePoint (WSS, SPS, MOSS, SP2010) and MCMS

First issue with SPDisposeCheck has been identified by the community

First issue with SPDisposeCheck has been identified by the community

  • Comments 1
  • Likes

One day out and we already have received feedback about a problem with SPDisposeCheck. ;-)

Here are the details:

Code like the one below is not recommended as it disposes the RootWeb - that is correctly identified by SPDisposeCheck!

        public void DND_RootWeb()

        {

            using (SPSite siteCollection = new SPSite("http://intranet.contoso.com"))

            {

                // Do Not Dispose Example

                using (SPWeb rootWeb = siteCollection.RootWeb)       // SPDisposeCheck reports "do not dispose" correctly

                {

                    string url = rootWeb.Url;

                }

            }

        }

But if a developer now changes his code like the following:

        public void DND_RootWeb2()

        {

            using (SPSite siteCollection = new SPSite("http://intranet.contoso.com"))

            {

                // Do Not Dispose Example

                SPWeb rootWeb = siteCollection.RootWeb;       // this should be allowed, but SPDisposeCheck reports warning

            }

        }

Then you suddenly get a warning like this:

SPDisposeCheckID_140:  Disposeable type not disposed: Microsoft.SharePoint.SPWeb ...

That warning is actually incorrect as in this situation it is recommended NOT to dispose the RootWeb.

The issue will be fixed in the next drop of SPDisposeCheck which is expected to be released in January.

Comments
  • I'm sorry but the reference counting of managed objects in the SharePoint object model is just plain broken...

    I do understand that this is a nightmare for you, since you need to be backward compatible but it is time to remove the unmanaged SPRequest code from SharePoint. If the unmanaged code would be removed you can manage the allocations internally in the ObjectModel.

    This way you can keep letting developers abuse the API  but at least it won't cause memory leaks.

    After an object has been disposed ANY interaction with this instance should throw an ObjectDisposed exception... It should NOT compensate for the bad client code and recreate a new instance..... (I think) SPDisposeCheck fails to find all these memory leaks.

    Happy holidays :)

    /Jonas

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Raw Html Fix