Welcome to MSDN Blogs Sign in | Join | Help

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

Published Tuesday, June 26, 2007 8:00 AM by BCLTeam

Comments

Tuesday, June 26, 2007 12:38 PM by MichaelGiagnocavo

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

Whats the efficient, generic version of BitArray?

Tuesday, June 26, 2007 12:42 PM by Peter Ritchie's MVP Blog

# System.Collections class are obsolete

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

Tuesday, June 26, 2007 12:44 PM by Inbar Gazit

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

Michael,

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.

Tuesday, June 26, 2007 2:06 PM by Peter Ritchie

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

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

Tuesday, June 26, 2007 3:08 PM by Pawel Pabich's blog

# Silverlight is getting smaller and smaller...

Silverlight is getting smaller and smaller...

Tuesday, June 26, 2007 3:08 PM by Blog

# Silverlight is getting smaller and smaller...

Silverlight is getting smaller and smaller...

Tuesday, June 26, 2007 6:36 PM by Method ~ of ~ failed

# silverlight: base class changes coming

silverlight: base class changes coming

Wednesday, June 27, 2007 1:51 AM by Jonathan Parker

# BCL Team Confirms Removal of old and unimportant Classes from Silverlight 1.1

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

Thursday, June 28, 2007 5:42 AM by lexp

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

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?

Thursday, June 28, 2007 11:37 AM by Inbar Gazit

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

lexp,

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.

Thursday, June 28, 2007 1:22 PM by Pete Brown's Blog

# Non-Generic Collections to be Removed From Silverlight 1.1

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

Friday, June 29, 2007 7:13 AM by JFo

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

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.

Friday, June 29, 2007 3:04 PM by inbarg

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

Jfo,

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

Friday, June 29, 2007 8:28 PM by JFo

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

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

F5

Result:

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]

Expected:

Contents of VisualCollection copied to secondList.

Also should work for secondList.AddRange();

Wednesday, July 04, 2007 9:38 PM by ひろえむの日々是勉強

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

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

Sunday, July 08, 2007 4:08 AM by I hate Spaghetti (code)

# Silverlight is getting smaller and smaller

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

Friday, July 20, 2007 5:01 AM by ディベロッパー製品開発統括部 Blog

# Silverlight 1.1の基本クラス ライブラリにおける非ジェネリック系のCollectionについて

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

Friday, July 20, 2007 6:08 AM by Noticias externas

# Silverlight 1.1の基本クラス ライブラリにおける非ジェネリック系のCollectionについて

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

Thursday, February 07, 2008 2:01 PM by Jesse Liberty - Silverlight Geek

# Tip of the Day - Time to move to Generic Collections for Silverlight.

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

Thursday, February 07, 2008 2:11 PM by Blogs

# Tip of the Day - Time to move to Generic Collections for Silverlight.

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

Wednesday, February 20, 2008 2:55 AM by Mirrored Blogs

# Tip of the Day - Time to move to Generic Collections for Silverlight.

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

Saturday, June 28, 2008 11:44 PM by DEVELOPMENT SITE - NOT MY PUBLIC BLOG

# Non-Generic Collections to be Removed From Silverlight 1.1

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

New Comments to this post are disabled
 
Page view tracker