Non-Generic Collections to be Removed from Silverlight [Inbar Gazit]

Those of you who are already using Silverlight 1.1 Alpha may have seen that the familiar non-generic collections were all marked as obsolete. This includes almost everything under the System.Collections namespace. You shouldn’t be too surprised. We’ve been telling you for a while that you should not be using these anymore and to instead use the generic collections in the System.Collections.Generic namespace. See the following blog post for more details on how and why to convert your non-generic collections.

While you can technically use obsolete types and only get warnings, we’re completely removing these types from Silverlight so we seriously advise you against using them.

The following types will be completely removed:

  • ArrayList
  • BitArray
  • CaseInsensitiveComparer
  • CaseInsensitiveHashCodeProvider
  • CollectionBase
  • Comparer
  • CompatibleComparer
  • DictionaryBase
  • EmptyReadOnlyDictionaryInternal
  • Hashtable
  • IHashCodeProvider
  • KeyValuePairs
  • ListDictionaryInternal
  • Queue
  • ReadOnlyCollectionBase
  • SortedList
  • Stack

On the other hand we decided to keep most of the non-generic interfaces (including those who were previously marked as obsolete):

  • IEnumerator
  • IEnumerable
  • ICollection
  • IComparer
  • IDictionary
  • IDictionaryEnumerator
  • DictionaryEntry
  • IEqualityComparer
  • IList

The non-generic collection interfaces are required for scenarios where you don’t know the type of T. Consider databinding as an example. Databinding works using non-generic methods today, and can deal with List<T> only because it implements the non-generic IList. There’s no easy way to get an arbitrary T in a non-generic method & manipulate it efficiently. While it may be possible to use Reflection to extract the T and use the type in a very late-bound fashion, this approach incurs a significant performance hit. We must continue to ship our non-generic collection interfaces.

Three other generic types were also removed. Queue<T>, Stack<T> and LinkedList<T> were removed from Silverlight. In this case it wasn’t because they were non-generic but because they are not considered to be part of the core set of types that we deemed essential to be provided with Silverlight. Remember that Silverlight is a very small download and should only include the smallest set of APIs that will allow for useful development. It’s very simple to implement Queue<T> and Stack<T> using List<T> and LinkedList<T> is just a different implementation of List<T> with different performance characteristics and so it’s not an essential part of our core collections group.

Expect to see these changes in a future preview release of Silverlight 1.1. Keep checking out our blog for the announcement about when and where...

Comments (22)

  1. MichaelGiagnocavo says:

    Whats the efficient, generic version of BitArray?

  2. Collection classes like ArrayList, SortedList, Stack and Hashtable will shortly be obsoleted (i.e. the

  3. Inbar Gazit says:


    You can use and Array or a List<Boolean> to get the functionality of a BitArray. However, if by efficient you mean that we don’t use unnecessary bits to store the data – that solution is not efficient. For Silverlight we decided that the need for BitArray is minimal and the workaround are decent enough. In the big framework you can still use BitArray if you have a need for efficiency or use generics if you don’t.

  4. Peter Ritchie says:

    Michael,  If you’re not using more than 32 bits, you might be able to use BitVector32.

  5. Silverlight is getting smaller and smaller…

  6. Blog says:

    Silverlight is getting smaller and smaller…

  7. silverlight: base class changes coming

  8. The BCL Team have confirmed via their blog that they will be removing some of the BCL types from Silverlight

  9. lexp says:

    1. Are there any plans to obsolete non-generic collections in future versions of .NET Framework?

    2. Is Silverlight a branch of .net framework code or you have a single source code tree?

  10. Inbar Gazit says:


    1. Not at this point. Check the blog often to be updated on our latest plans.

    2. We have a single source code and we build it separately for Silverlight from the big framework so that we only have parts of it in Silverlight. The rest should be the same in both frameworks for the most part.

  11. Luckily the interfaces are still left in. They were marked obsolete, but I had some binding scenarious

  12. JFo says:

    Can you make it so List<T> is completely implemented?

    The two I miss are:

    List<T> CTOR that takes an IEnumerable

    and the List<T> AddRange.

    If not already there, it would be nice to have an Observable<T> collection as well so we can know when the collection changed through an event.

  13. MSDNArchive says:


    I’m not sure why you think these are not implemented in Silverlight but this is not the case. List<T> has the same constructors as in 2.0/3.5 and also has the AddRange method implemented. Please take a second look to make sure.

    As for Observable<T>, that’s an interesting idea…

  14. JFo says:

    You’re right I think the bug is in agclr.dll – whoever owns that.  Can you file it?

    Title: List<T> CTOR and AddRange do not work with VisualCollection

    The issue seems to be with their visual collection.

    In Orcas Beta 1, Silverlight Alpha 1.1

    Create new silverlight project

    In Page.xaml add a <Rectangle Fill="red"/> to the <Canvas>

    In Page.xaml.cs, add the following line to the Page_Loaded event:

       List<Visual> secondList = new List<Visual>(this.Children);

    Turn on Debug -> Catch Exceptions



    Not supported exception

    agclr.dll!MS.Internal.Collection<System.Windows.Media.Visual>.CopyTo(System.Windows.Media.Visual[] array = {System.Windows.Media.Visual[1]}, int index = 0) + 0x2b bytes

    mscorlib.dll!System.Collections.Generic.List<System.Windows.Media.Visual>.List(System.Collections.Generic.IEnumerable<System.Windows.Media.Visual> collection = {System.Windows.Media.VisualCollection}) + 0x14f bytes

    > SilverlightProject1!SilverlightProject1.Page.Page_Loaded(object o = {SilverlightProject1.Page}, System.EventArgs e = {System.EventArgs}) Line 23 + 0x20 bytes C#

    [Managed to Native Transition]

    agclr.dll!MS.Internal.JoltHelper.FireEvent(System.IntPtr unmanagedObj = 52477992, string objectName = "System.Windows.Controls.Canvas", System.IntPtr unmanagedObjArgs = 0, string objectNameArgs = null, string eventName = "M@1") + 0x281 bytes

    [Appdomain Transition]

    [Native to Managed Transition]


    Contents of VisualCollection copied to secondList.

    Also should work for secondList.AddRange();

  15. Silverlight 1.1ではGenericでないCollectionはなくなるそうな。

  16. According to Inbar Gazit almost all of the System.Collection classes (and Queue&lt;T&gt;, Stack&lt;T&gt;

  17. Silverlight 1.1の基本クラス ライブラリにおける非ジェネリック系のCollectionについて Alpha版で調査をなされていらっしゃるお客さまも多いのではと思いますが、Silverlightのランタイムにおいて非ジェネリック系のコレクション

  18. Alpha版で調査をなされていらっしゃるお客さまも多いのではと思いますが、Silverlightのランタイムにおいて非ジェネリック系のコレクション クラスを取り除く予定でございます。また、ジェネリックのコレクション

  19. In Silverlight 1.1 the non-generic collections were marked obsolete. We have announced that the non-generic

  20. Blogs says:

    In Silverlight 1.1 the non-generic collections were marked obsolete. We have announced that the non-generic

  21. In Silverlight 1.1 the non-generic collections were marked obsolete. We have announced that the non-generic

  22. Luckily the interfaces are still left in. They were marked obsolete, but I had some binding scenarious with my home-made drop-down list box (for the current project) that just didn&#39;t work without IList, as I didn&#39;t know &lt;T&gt; Here&#39;s the

Skip to main content