CollectionView does not dispose SourceCollection enumerator synchronously - by Daniele Mancini

Status : 


Sign in
to vote
ID 513500 Comments
Status Active Workarounds
Type Bug Repros 5
Opened 11/23/2009 6:13:22 AM
Access Restriction Public


An internal constructor of the CollectionView class
internal CollectionView(IEnumerable collection, int moveToFirst)
creates an enumerator locally and does not dispose it properly.

Even if this fact has no drawbacks when dealing with pre-defined enumerators, it can be problematic and dangerous in case the underlying collection enumerator takes into account synchronization or requires to be disposed in the same thread that created it.

Since one of Microsoft best practices states that IDisposable objects should be wrapped inside a 'using' block (like the foreach does), and I tend to think that enumerators are not supposed to be shared among different threads, this can be indeed considered a bug.

In short, the current implementation does not allow for a synchronous enumerator dispose.
Sign in to post a comment.
Posted by Daniele Mancini on 8/2/2012 at 1:40 AM
The bug has been reported on 11/23/2009.
The post made on 3/4/2010 at 11:42 AM admits the triviality of such fix.
The post on 4/26/2011 at 1:42 PM states that the issue is more generic than I thought, and it is *nearly* fixed.
Now, after more than 3 years have passed, you state that this is not going to be fixed, since you claim that you are more interested in bugs that affect the highest number of developers.
Unfortunally this bug affects *all* developers, it's just that the after-effects are noticed by *some* developers, and *few* developers bother upvoting. Moreover, if a quick fix takes more than 3 years, every sane developer is bound to find a different approach and find a solution for himself, instead of relying on a bugfix.
This is truly disappointing.
Posted by Microsoft on 8/2/2012 at 12:53 AM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.
Posted by Microsoft on 4/26/2011 at 1:42 PM
This is (nearly) fixed for the next release. There are some enumerators that WPF keeps alive indefinitely; we will now dispose all other enumerators (that are disposable) except for these. The enumerator cited in the bug report - obtained by the CollectionView constructor - will be disposed.

The long-lived enumerators only arise when you use an object as a collection (e.g. as ItemsControl.ItemsSource or CollectionViewSource.Source) and the object does not implement INotifyCollectionChanged nor one of the collection interfaces IList or IBindingList. E.g. it implements IEnumerable (only). Most apps don't use this sort of object.
Posted by Eric Ouellet on 4/14/2011 at 2:12 PM
I reported the same bug 661539.

This bug is really important and have deep performance impact on our product due to the fact that we can't use MultiThreaded collection.

Éric Ouellet
Posted by Microsoft on 3/4/2010 at 11:42 AM
It arrived too late for .Net 4.0. We will consider this for the next release. (And I agree it is simple - it's quite likely to be fixed.)
Posted by Daniele Mancini on 3/4/2010 at 3:59 AM
I would like to know if this is issue (which is quite evident and whose solution is really simple) is really going to be fixed.
More than 2 months have passed and this bug report, is still Active...
Posted by Microsoft on 11/30/2009 at 4:48 PM
Thanks for raising this issue. Yes, we should call Dispose after finishing with an enumerator. We will consider this in a future release.
Posted by Microsoft on 11/25/2009 at 2:11 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Posted by Microsoft on 11/24/2009 at 4:09 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(