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()
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.
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 :)