Difference between Collection<Type> and List<Type>

It seems that collection is originally a visual basic type

#from the msdn help about collections in c#
The Visual Basic Collection object provides a convenient way to refer to a related group of items as a single object. The items, or elements, in a collection need only be related by the fact that they exist in the collection. Elements of a collection do not have to share the same data type.

and if you put <Type> after it its just the same as List<Type> but from the VisualBasic Language

I think it may have started out that way, but it seems tehre is some difference now since FxCop prefers one over another in various situations.

Therefore I am looking for technical details about when to use each - what is the difference?  Advantages? Disadvantages?

Have a look here:

http://msdn2.microsoft.com/en-us/library/6sh2ey19.aspx (List<T>)
http://msdn2.microsoft.com/en-us/library/ms132397.aspx (Collection<T>)


To summarize:

Collection:
The Collection class can be used immediately by creating an instance of one of its constructed types; all you have to do is specify the type of object to be contained in the collection. In addition, you can derive your own collection type from any constructed type, or derive a generic collection type from the Collection class itself.

The Collection class provides protected methods that can be used to customize its behavior when adding and removing items, clearing the collection, or setting the value of an existing item.

A Collection instance is always modifiable. See ReadOnlyCollection for a read-only version of this class.

Elements in this collection can be accessed using an integer index. Indexes in this collection are zero-based.

Collection accepts a null reference (Nothing in Visual Basic) as a valid value for reference types and allows duplicate elements.

Notes to Implementers This base class is provided to make it easier for implementers to create a custom collection. Implementers are encouraged to extend this base class instead of creating their own. this page

List:
The List class is the generic equivalent of the ArrayList class. It implements the IList generic interface using an array whose size is dynamically increased as required.

The List class uses both an equality comparer and an ordering comparer.

Methods such as Contains, IndexOf, LastIndexOf, and Remove use an equality comparer for the list elements. The default equality comparer for type T is determined as follows. If type T implements the IEquatable generic interface, then the equality comparer is the Equals method of that interface; otherwise, the default equality comparer is Object.Equals(Object).

Methods such as BinarySearch and Sort use an ordering comparer for the list elements. The default comparer for type T is determined as follows. If type T implements the IComparable generic interface, then the default comparer is the CompareTo method of that interface; otherwise, if type T implements the nongeneric IComparable interface, then the default comparer is the CompareTo method of that interface. If type T implements neither interface, then there is no default comparer, and a comparer or comparison delegate must be provided explicitly.

The List is not guaranteed to be sorted. You must sort the List before performing operations (such as BinarySearch) that require the List to be sorted.

Elements in this collection can be accessed using an integer index. Indexes in this collection are zero-based.

List accepts a null reference (Nothing in Visual Basic) as a valid value for reference types and allows duplicate elements.

Performance Considerations
In deciding whether to use the List or ArrayList class, both of which have similar functionality, remember that the List class performs better in most cases and is type safe. If a reference type is used for type T of the List class, the behavior of the two classes is identical. However, if a value type is used for type T, you need to consider implementation and boxing issues.

If a value type is used for type T, the compiler generates an implementation of the List class specifically for that value type. That means a list element of a List object does not have to be boxed before the element can be used, and after about 500 list elements are created the memory saved not boxing list elements is greater than the memory used to generate the class implementation.

Make certain the value type used for type T implements the IEquatable generic interface. If not, methods such as Contains must call the Object.Equals(Object) method, which boxes the affected list element. If the value type implements the IComparable interface and you own the source code, also implement the IComparable generic interface to prevent the BinarySearch and Sort methods from boxing list elements. If you do not own the source code, pass an IComparer object to the BinarySearch and Sort methods

It is to your advantage to use the type-specific implementation of the List class instead of using the ArrayList class or writing a strongly typed wrapper collection yourself. The reason is your implementation must do what the .NET Framework does for you already, and the common language runtime can share Microsoft intermediate language code and metadata, which your implementation cannot.

Yes I have read the msdn pages.  They explain each one, and lists in relation to array lists or arrays, but not in realtion to each other.  I already knew the information provided there.

I have done the msdn research and did not find the answer of comparing them to each other which is waht I am looking for.

They each only tell about the individual ones.

Ok, well. I haven't worked much with .NET 2.0 yet, but from what I understand Collection<T> is a base class for other kind of collections. So Collection<T> is meant so you can create your own type of collections, while the List<T> is a fully qualified implementation of the IList interface, which does not have any default implementation (IList that is).

So for example:

public Collection<T> Data1 {
  get {
  return null;
}
}

vs.

public List<T> Data2 {
  get {
  return null;
}
}

Data1 can give back anything which is a Collection and List only everything which is a list. For the rest it seems pretty much the same.

I don't understand any difference there....

We have some code and it seems to work the same whether we have it as List<type> or COllection<type>.  We are trying to figure out why one would be better over the other, in what circumstances, and why.  Are there times where they are equal?

This is the type of information we are looking for - technical details.

I think in practical use they are the same 99% of the times. Only in cases in which you totally have no clue what kind of Collection you will be getting/using you should use Collection<T>, since that's a generic implementation of everything which is a Collection whereas List<T> is a specific implementation. But since both Collection<T> as List<T> implement IList you would rather ask myself: "Why use Collection<T> and not IList" in this case?".

So basicly according to Microsoft you should always use List<T> when you know that you are getting are getting back, but actually there isn't a real difference. That's what I can make out from what I've read untill now. So in your case, i think you should just make a choice, and that there is not really difference.

Have you tried adding millions of objects into them and reading them again out? That will definatly show you if there are any differences in implementation, but I doubt there are.

Okay I have found out a bit more - which is the type of information I have been searching for:

List<type> has additional functionality that Collection<type> does not.  Specifically the FindAll() and ForEach() are two examples

Collection<type> has more limited fuctionality, but has virtual functions defined so that you can override events such as when items are added or changed, which you cannot do with a List.

Therefore when using inheritance if you forsee a need to overload these events then a collcetion should be used.

But now I am curious about - what if you want the extra list functionality and don't see a need for the overload in the future?