Monthly Archives: February 2014

Dynamic Objects

The IDynamicMetaObjectProvider interface represents an object that can be late bound.

Microsoft supplies to implementations of this interface out of the box. DynamicObject and ExpandoObject.

DynamicObject

The DynamicObject is mean’t to be used as a base class for the user’s own dynamic object and hence has a protected constructor. The idea is that we can create our own dynamic object and handle any attempted access to member properties or methods etc. at runtime.

For example here’s an implementation of a dynamic object which adds (at runtime) a method which takes no arguments and returns a string

public class MyObject : DynamicObject
{
   public override bool TryGetMember(
            GetMemberBinder binder, out object result)
   {
      result = null;
      if (binder.Name == "GetName")
      {
         result = new Func<string>(() => "Hello World");
         return true;
      }
      return false;
   }
}

If we wanted to handle a property named GetName we’d simply return a string, not a function. The TryGetMember is used for methods with no arguments or get properties, when arguments are supplied to a method we should override TryInvokeMember.

ExpandoObject

Unlike DynamicObject an ExpandoObject can be instantiated and then we can add methods and properties to it via it’s IDictionary interfaces.

So for example, let’s create an ExpandoObject and add a new method

dynamic d = new ExpandoObject();

((IDictionary<string, object>)d).Add("GetName", new Func<string>(() => "Hello World"));

Console.WriteLine(d.GetName());

As you can see we must ofcourse declare our variable as dynamic otherwise the use of GetName will cause the compilation error

System.Dynamic.ExpandoObject’ does not contain a definition for ‘GetName’ and no extension method ‘GetName’ accepting a first argument of type ‘System.Dynamic.ExpandoObject’ could be found (are you missing a using directive or an assembly reference?)

We also need to cast the instance to IDictionary<string, object> as access to the Add method needs to go through an explicit interface.

So as you see, we can add to the ExpandoObject at runtime, unlike a DynamicObject derived class where only the derived class would be able to add to the object at runtime (obviously assuming we don’t add methods to allow this ourselves).

Dynamically loading assemblies into Caliburn Micro

I want to be able to load the views/viewmodel assemblies into Caliburn Micro dynamically, i.e. instead of adding references to them to the project….

Well, we’ve got two ways of loading assemblies (that I’m currently aware of). The first is via the Bootstrapper and the second can be handled pretty much anywhere. Both examples below are shown using the DLL name, but ofcourse we could take this further via configuration files, build out own attributes and so on, but I leave that decision to the user.

So through Bootstrapper simply overload SelectAssemblies, for example

protected override IEnumerable<Assembly> SelectAssemblies()
{
   string path = Path.GetDirectoryName(
                    Assembly.GetExecutingAssembly().Location);
   return base.SelectAssemblies().Concat(
         new Assembly[] 
         { 
            Assembly.LoadFile(Path.Combine(path, "MyViews.dll"))
         });
}

However if you’re using a plugin approach, possibly where you allow the user to select a plugin DLL or the likes, then at the point you want to load the assembly you could write something like the following

string path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
Assembly a = Assembly.LoadFile(Path.Combine(path, "Rabbit.Controls.dll"));
AssemblySource.Instance.Add(a);

The key here is the AssemblySource singleton and adding assemblies to the IObservableCollection Instance.

Binding to a listbox and selected item using Caliburn Micro

This will work with a listbox or combo box.

So, using Caliburn Micro we use convention based naming for the ItemsSource as follows

<ListBox x:Name="Employees" />

But as you see there’s nothing for SelectedItem, instead it is taken that the property name in the view model for the selected item will be SelectedEmployee, i.e.

public class EmployeesViewModel : PropertyChangedBase
{
   private EmployeeViewModel selected;

   public ObservableCollection<EmployeeViewModel> Employees { get; private set; }

   public EmployeeViewModel SelectedEmployee
   {
      get { return selected; }
      set
      {
         if (selected != value)
         {
            selected = value;
            NotifyOfPropertyChange();
         }
      }
   }
}

NinjectModules

NinjectModules allow us to define bindings in assemblies without the need to resort to passing around an instance of the IKernel.

So let’s look at an example. We have an EXE project and another project which contains the common interfaces used in the application. Let’s assume we have an IAdministrationSettings interface in the “common” project. The main application has classes and/or properties which have service dependencies on IAdministrationSettings.

Now we create a third project which will contain the implementations of the interfaces used in our application. So it’s got a reference to the common interfaces project/DLL but has no knowledge of the EXE and likewise the EXE has no knowledge of the implementation project.

So we want to now bind our implementation to the interface and have it automatically injected into our EXE.

In the implementation project we add the usual NInject references (or use NuGet to do it) and create a file, mines called Module.cs but the name doesn’t matter. Then we place the following code into the file

public class Module : NinjectModule
{
   public override void Load()
   {
      Bind<IAdministrationSettings>().To<AdministrationSettings>().InSingletonScope();
   }
}

We’ve declared a NinjectModule (there could be more than one) which define the bindings of our interface(s) to implementation(s), but we now need Ninject in the EXE to load these modules and hence allow it to bind the correct implementation, so we use the following code in the EXE

IKernel kernel = new StandardKernel();
kernel.Load("*.dll");

The above used the wildcard to load any/all DLL’s which have NinjectModules, alternatively we could store the implementations in “known” locations or ofcourse put the actual path to the DLL into this method.

Now Ninject will automatically handle the bindings.

C# code for accessing the network through a proxy server

How to setup proxy authentication and details

ICredentials credentials = CredentialCache.DefaultCredentials;
IWebProxy proxy = new WebProxy(proxyServerHost, proxyServerPort);
proxy.Credentials = credentials;

The code (above) creates a set of credentials, in this case we get the user’s DefaultCredentials and ultimately places the credentials into the IWebProxy.

The IWebProxy is then instantiated with the host name and the port of the proxy server.

Let’s use the proxy

Now to use the web proxy obviously requires the library/framework to support proxies. So this is just one example using the .NET WebClient class.

using (WebClient wc = new WebClient())
{
   if(proxy != null)
   {
      wc.Proxy = proxy;
   }
   byte[] data = wc.DownloadData(url);
}

Code Contracts

Elevator pitch

Code contracts allow us to define preconditions, post conditions and the likes in our code. These are constructs I first read about when doing a (very) little bit of Eiffel development.

Visual Studio additions

Before we get into Code Contracts let’s just note that they are available in .NET 4.5 but we need to enable their usage and here we need to install a couple of additions to Visual Studio.

So if you’re running Visual Studio 2012 goto Tools | Extensions and Updates and search online for Code Contract Tools – install this. Then find Code Contracts Editor Extensions VS2012 and install this. You’ll have to restart Visual Studio to see the new installs working. So go ahead and do that.

If Visual Studio 2013 I just install Code Contract Tools.

This will install some addition static analysis tools etc. which we’ll look at later, for now let’s code…

Using Code Contracts

Predconditions

Often in our code we’ll have methods which check the arguments passed to a method or possibly check class wide variables have been set etc. Usually the code might take the following form

public void Analyze(string data)
{
   if(data == null)
      throw new ArgumentNullException("data");

   // do something
}

Well first off we can now replace this with a Code Contract precondition. The precondition ofcourse states that for this method to run, this or these preconditions must be met.

public void Analyze(string data)
{
   Contract.Requires<ArgumentNullException>(line != null)
}

We could have specified the same precondition without the ArgumentNullException and a ContractException would be thrown instead.

Postconditions

A postcondition specifies the state of a method when it ends. For example, we can declare that we’ll never return a null by declaring the following contract

public static string Analyze(string line)
{
   Contract.Requires<ArgumentNullException>(line != null);
   Contract.Ensures(Contract.Result<string>() != null);
   
   // do something
   
   return result;
}

Now if we actually did attempt to return null we’d get a ContractException.

Assumptions

So, we can define pre and postconditions, but also we can define assumptions. Basically let’s assume we have our Analyze method (above) but without the pre or postconditions and we want to declare an assumption that the result from Analyze will not be null, we could write

public string Analyze(string data)
{
   // do something

   return result;
}

static void Main(string[] args)
{
   string result = Analyze("Some Text");

   Contract.Assume(result != null);

   // do something with result
}

Obviously if result is set to null, our contract is violated and the ContractException will be thrown.

Object Invariants

An object invariant basically defines the state of an object. So for example, let’s assume we have a Person class as below

public class Person
{
   public Person(string firstName, string lastName)
   {
      FirstName = firstName;
      LastName = lastName;
   }

   public string FirstName { get; set; }
   public string LastName { get; set; }
}

It may be that we want to define a contract which states that FirstName and LastName are not null. We could add preconditions to the constructor – but what if we also wanted to define a contract that says FirstName and LastName are never null, not just within the contructor’s scope.

Now we can add a ContractInvariantMethod as below

public class Person
{
   public Person(string firstName, string lastName)
   {
      FirstName = firstName;
      LastName = lastName;
   }

   public string FirstName { get; set; }
   public string LastName { get; set; }

   [ContractInvariantMethod]
   private void ContractInvariant()
   {
      Contract.Invariant(FirstName != null && LastName != null);
   }
}

Note: We could have had the left and right parts of the && in different Contract.Invariant declarations if we wished, so basically we can have multiple Contract.Invariant in this method.

The method name can be anything you like and can only contain Contract.Invariant statements. A compile time error will occur if you have other code in this method.

Now when we create a Person object if either FirstName or LastName are set to null a ContractException will occur, but better still let’s assume we add a new method to the class which sets one of these variables to null. The ContractInvariantMethod will be called and the contract will be violated leading to a ContactException.

Contracts on interfaces

An interesting use of contracts is with interfaces. Basically if we define an interface it would be nice if we could declare the contract definitions against the interface. Then any implementation could “inherit” the contract definitions.

So let’s look at our Person class again but now add an interface and define some contracts on the interface

[ContractClass(typeof(IPersonContract))]
public interface IPerson
{
   string FirstName { get; set; }
   string LastName { get; set; }			
}

[ContractClassFor(typeof(IPerson))]
internal abstract class IPersonContract : IPerson
{
   public string FirstName
   {
      get 
      { 
         Contract.Ensures(Contract.Result<string>() != null);
         return default(string); 
      }
      set { Contract.Requires(value != null); }
   }

   public string LastName
   {
      get 
      { 
         Contract.Ensures(Contract.Result<string>() != null);
         return default(string); 
      }
      set { Contract.Requires(value != null); }
   }
}

public class Person : IPerson
{
   public Person(string firstName, string lastName)
   {
      FirstName = firstName;
      LastName = lastName;
   }

   public string FirstName { get; set; }
   public string LastName { get; set; }
}

So the interface is a standard interface except that we are declaring (using the ContractClass attribute) that the IPersonContract class includes contract definitions for the interfaces. Likewise on the IPersonContract abstract class. Yes, it’s mean’t to be abstract and implement the interface. Now when we return values, just use default(<type>) so all will compile and add your pre or postconditions. Unfortunately it doesn’t look like we can add a ContractInvariantMethod method to this abstract class (or at least we can but it doesn’t appear to do anything in the current release of .NET).

ContractAbbreviator

The ContractAbbreviatorAttribute is used on a method to denote it contains contract data which, when the method is called from another method in essence runs the contract checks in that method – eh ? It’s a bit like creating a C style macro and having it inlined in a method – eh ?

It’s a was to reuse contracts.

Okay let’s see an example

public class Person
{
   public string FirstName { get; set; }
   public string LastName { get; set; }

   [ContractAbbreviator]
   private void Validate()
   {
      Contract.Ensures(FirstName != null);
      Contract.Ensures(LastName != null);
   }

   public void Amend()
   {
      Validate();
   }
}

Now when we run Amend (with FirstName and/or LastName set to null) the exception occurs from the Amend method, as if the Contract.Ensure’s replaced the Validate call.

Based upon the above information it would come as no surprise to find out that when the ContractAbbreviator attribute is used on a method (and ofcourse the method is called from another method), the compiler does indeed place the contract code into the calling method and replaces the instruments within the Validate method (in the above example) with a nop. When the attribute is not included we really are calling another method.

Obviously this means we can reuse the Amend method now in more than one method (or more specifically the contracts contained within the method), so we’ve created a reusable set of contracts. If you remove the ContractAbbreviator attribute then run as previously suggested, the validation failure will occur in the Validate method.

Visual Studio Plugin

At the start of this post we installed a couple of code contract specific plugins (in VS2012 and only one in VS2013). These added the property editor into the project properties for enabling etc. Code Contracts. But they also installed editor warnings.

If you check the “Perform Static Contract Checking” option in the Code Contract property page, then rebuild your project. Static analysis will take place and may display warnings. For example if your code looked like this 

public void Analyze(string data)
{
   Contract.Requires<ArgumentNullException>(line != null)
}

static void Main(string[] args)
{
   Analyze(null);
}

We would get warnings stating CodeContracts: requires is false: line != null. Along with a red squiggly underline of the code Analyze(null) and a tooltip popup showing the warning message.

So giving us an indication early on of possible contract violations.

References

Code Contracts User Manual
Code Contracts

Entity Framework – Tips and Tricks

How do I stop my Code First implementation creating a new database

It might seem a strange request, why use Code First then. But let’s assume you’ve created a Code First EF model and then switched to creating the db using SQL scripts and want ensure the EF application doesn’t try to create the db.

Database.SetInitializer(null);

By default the initializer would be set to CreateDatabaseIfNotExists.

See also Database.SetInitializer.

There is already an open DataReader associated with this Command which must be closed first

An EntityCommandExecutionException with the message “There is already an open DataReader associated with this Command which must be closed first” occurred whilst implementing a bit of code to list all the ProductTypes in a database.

The solution appears to be add

MultipleActiveResultSets=True

to your connection string

I’ll add more to this post as or when I remember

Some Linq Patterns

What follows is a list of a few patterns for specific tasks using LINQ

Combining two lists

We can combine two lists, where duplicates are removed using

var a = new List {0, 2, 3, 4, 5, 6};
var b = new List { 0, 1, 3, 4, 6, 6 };

var union = a.Union(b);
[/code]

Find the common items in both lists

var a = new List<int> {0, 2, 3, 4, 5, 6};
var b = new List<int> { 0, 1, 3, 4, 6, 6 };

var intersection = a.Intersect(b);

we can also use the lambda expression join

var l1 = new List<int> {1, 2, 4, 5};
var l2 = new List<int> { 0, 2, 4, 6 };

var r = from a in l1 join b in l2 on a equals b select a;

Find the differences between two lists

This will find the items in the first list which are not in the second list

var listA = new List<int> {0, 2, 3, 4, 5, 6};
var listB = new List<int> { 0, 1, 3, 4, 6, 6 };

var differences = from a in listA where listB.All(i => i != a) select a;

Combining every item in one list with every item in another list

Here we’re going to do a cross join, where the output enumerable is a made up of each element from the first list, combined with each element of the second list

var l1 = new List<int> {1, 2};
var l2 = new List<int> { 0, 2 };

var crossjoin = from a in l1
       from b in l2
       select new {a, b};

The output would be

1 0
1 2
2 0
2 2

I’ll add more as and when I remember to add them.

Creating a custom Linq Provider

To create a custom LINQ provider we need to implement the interfaces, IQueryable or IOrderedQueryable and IQueryProvider.

This is a summary of several posts/blogs I’ve read on the subject and source code available on github etc. See References below.

IQueryable<T>

To implement a minimal LINQ provider we need to implement IQueryable<>. This interface inherits from IEnumerable. The actual IQueryable methods are minimal

  1. ElementType
  2. Expression
  3. Provider

IOrderedQueryable<T>

If we want to support the sorting query operators, then we need to implement IOrderedQueryable<T>.

IOrderedQueryable inherits from IEnumerable, IEnumerable<T>, IOrderedQueryable, IQueryable, and IQueryable<T>.

We can implement an IOrderedQueryable that’s reusable for most situations, as follows

public class Queryable<T> : IOrderedQueryable<T>
{
   public Queryable(IQueryContext queryContext)
   {
      Initialize(new QueryProvider(queryContext), null);
   }

   public Queryable(IQueryProvider provider)
   {
     Initialize(provider, null);
   }

   internal Queryable(IQueryProvider provider, Expression expression)
   {
      Initialize(provider, expression);
   }

   private void Initialize(IQueryProvider provider, Expression expression)
   {
      if (provider == null)
         throw new ArgumentNullException("provider");
      if (expression != null && !typeof(IQueryable<T>).
             IsAssignableFrom(expression.Type))
         throw new ArgumentException(
              String.Format("Not assignable from {0}", expression.Type), "expression");

      Provider = provider;
      Expression = expression ?? Expression.Constant(this);
   }

   public IEnumerator<T> GetEnumerator()
   {
      return (Provider.Execute<IEnumerable<T>>(Expression)).GetEnumerator();
   }

   System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
   {
      return (Provider.Execute<System.Collections.IEnumerable>(Expression)).GetEnumerator();
   }

   public Type ElementType
   {
      get { return typeof(T); }
   }

   public Expression Expression { get; private set; }
   public IQueryProvider Provider { get; private set; }
}

Note: The IQueryContext is not part of the LINQ interfaces but one I’ve created to allow me to abstract the actual “custom” part of the code and allow maximum reuse of default functionality.

IQueryProvider

The IQueryProvider basically requires two methods (a generic and non-generic version of both) to be implemented. Obviously the generic versions are for strongly typed and the non-generic are loosely typed.

CreateQuery

The CreateQuery method is used to create a new instance of an IQueryable based upon the supplied expression tree.

Execute

The Execute method is used to actually execute a query expression, i.e. in a custom provider we will get the data from the datasource, for example a webservice or database etc. and it’s in the Execute method that we both get the data and do any conversion to, say SQL or the likes (if the LINQ query ultimately queries some other system.

An example of an implementation for an IQueryProvider might look like this…

public class QueryProvider : IQueryProvider
{
   private readonly IQueryContext queryContext;

   public QueryProvider(IQueryContext queryContext)
   {
      this.queryContext = queryContext;
   }

   public virtual IQueryable CreateQuery(Expression expression)
   {
      Type elementType = TypeSystem.GetElementType(expression.Type);
      try
      {
         return                
            (IQueryable)Activator.CreateInstance(typeof(Queryable<>).
                   MakeGenericType(elementType), new object[] { this, expression });
      }
      catch (TargetInvocationException e)
      {
         throw e.InnerException;
      }
   }

   public virtual IQueryable<T> CreateQuery<T>(Expression expression)
   {
      return new Queryable<T>(this, expression);
   }

   object IQueryProvider.Execute(Expression expression)
   {
      return queryContext.Execute(expression, false);
   }

   T IQueryProvider.Execute<T>(Expression expression)
   {
      return (T)queryContext.Execute(expression, 
                 (typeof(T).Name == "IEnumerable`1"));
   }
}

Note: Again, the IQueryContext is not part of the LINQ interfaces but one I’ve created to allow me to abstract the actual “custom” part of the code and allow maximum reuse of default functionality.

The TypeSystem class is taken from the post Walkthrough: Creating an IQueryable LINQ Provider

IQueryContext

The above shows some LINQ interfaces and some sample implementations. I’ve pointed out that IQueryContext is not part of LINQ but is instead something I’ve created (based upon reading various other implementations) to allow me to abstract the actual LINQ provider code specific to my provider’s implementation. Ofcourse we could have derived from QueryProvider, but for now we “plug-in” the data context instead. To change the implementation to derive from QueryProvider simple remove the IQueryContext (also from the Queryable implementation) and override the Execute methods.

For now I’ll continue this post using the IQueryContext, so here’s the interface

public interface IQueryContext
{
   object Execute(Expression expression, bool isEnumerable);
}

Implementing the IQueryContext

Whether the implementation of the actual Execute code (on the IQueryProvider) is abstracted into the IQueryContext or implemented within an alternate implementation of IQueryProvider. This is where the fun of actually “running” the LINQ query against your custom provider takes place.

When writing something like this…

var ctx = new Queryable<string>(new CustomContext())

var query = from s in ctx where s.StartsWith("T") select s;

what we are really doing is creating the query. Hence the CreateQuery methods on the IQueryProvider are called, but the actual data source or whatever supplies the data for your custom LINQ provider should not be called until we reach the execution phase, this is known as deferred execution. The execution phase takes place when we enumerate over the query or call methods, such as Count() etc. against a query.

foreach (var q in query)
{
   Console.WriteLine(q);
}

So at the point that we GetEnumerator implicitly via the foreach loop, that’s when the Execute method is called.

Executing the query

So, the Execute method is called and we will have an expression tree defined by LINQ supplied as an argument. We now need to translate that query into something useful, i.e. turn it into an SQL query for a custom database LINQ provider and then get the data for this query, or get data from a webservice and allow the query to be executed against the returned data etc.

As the actual decoding of the Expression is a fairly large subject in itself, I’ll leave that for another post, but suffice to say, there’s a lot we need to implement to duplicate some if not all of the “standard” LINQ query operators etc.

References

Walkthrough: Creating an IQueryable LINQ Provider
LINQ: Building an IQueryable provider series
LINQ and Deferred Execution

.NET collections refresher

I’ve been writing C#/.NET code for a long time, but every now and then I feel the need to give myself a refresher on the basics and it usually results in finding features that have been added which I knew nothing about. You know how you get used to using classes so look no further. Well here’s my refresher on the .NET collection classes as of .NET 4.5

ArrayList

The ArrayList is a wrapper around a standard object[]. It’s weakly typed and may suffer in performance tests against a generic array type such as a List<T> due to boxing/unboxing.

Unlike a standard object[] declared arrays, multidimensional arrays elements are not directly supported. Although ofcourse you can create an ArrayList or ArrayLists.

BitArray

The BitArray class is a specialized collection for handling an array of bits. It allows us to manipulate the bits in various ways, but lacks bit shifting (for example).

BlockingCollection<T>

The BlockingCollection class wraps an IProducerConsumerCollection<T> to allow thread-safe adding and removing of items. It also offers bounding capabilities.

ConcurrentBag<T>

The ConcurrentBag is a thread-safe bag. Bags are used to store objects with no concern for ordering. They support duplicates and nulls.

ConcurrentDictionary<TKey, TValue>

The ConcurrentDictionary is a thread-safe dictionary.

ConcurrentQueue<T>

The ConcurrentQueue is a thread-safe Queue (FIFO collection).

ConcurrentStack<T>

The ConcurrentStack is a thread-safe Queue (LIFO collection).

Collection<T>

The Collection class is a base class for generic collections. Whilst you can instantiate a Collection<T> directly (i.e. it’s not abstract) it’s designed more from the point of view of extensibility, i.e. deriving you own collection type from it. It only really differs from a List<T>, in that it offersvirtual methods for you to overload to customize your collection, whereas a List<T> doesn’t offer such extensibility.

Dictionary<TKey, TValue>

A key/value generic class. Duplicates are not allowed as keys, nor are nulls. For a thread-safe implementation, look at ConcurrentDictionary<TKey, TValue>.

HashSet<T>

The HashSet<T> is a set collection and thus cannot contain duplicate elements. Elements are not held in any particular order. It is aimed a set type operations, such as IntersectWith, Overlap etc.

Hashtable

The Hashtable stores key/value pairs which are organised based upon the hash code of the key. As per the Dictionary class, keys cannot be null and duplicates are not allowed. Basically it’s a weakly typed Dictionary.

HybridDictionary

The HybridDictionary is a weakly typed Dictionary which can switch between using the ListDictionary for when there’s only a few items stored and then switching to the Hashtable when the collection gets large.

ImmutableDictionary<T>

The ImmutableDictionary is, simply put, an immutable Dictionary.

See also ImmutableInterlocked .

ImmutableHashSet<T>

The ImmutableHashSet is, simply put, an immutable HashSet.

See also ImmutableInterlocked .

ImmutableList<T>

The ImmutableList is, simply put, an immutable List.

See also ImmutableInterlocked .

ImmutableQueue<T>

The ImmutableQueue is, simply put, an immutable Queue.

See also ImmutableInterlocked .

ImmutableSortedDictionary<T>

The ImmutableSortedDictionary is, simply put, an immutable SortedDictionary.

See also ImmutableInterlocked .

ImmutableSortedSet<T>

The ImmutableSortedSet is, simply put, an immutable SortedSet.

See also ImmutableInterlocked .

ImmutableStack<T>

The ImmutableStack is, simply put, an immutable Stack.

See also ImmutableInterlocked .

KeyedCollection<TKey, TItem>

The KeyedCollection is an abstract class which is a hybrid between a collection based upon an IList<T> and an IDictionary<TKey, TItem>. Unlike a Dictionary, the element stored is not a key/value pair. It’s key is embedded in it’s value.

LinkedList<T>

The LinkedList class is really that, a doubly linked list. Obviously this means insertion and removal of items are O(1) operations. Copying of elements requires far less memory than copying of array like structures, and obviously when adding more an more items the underlying data structure itself does not need to resize as an array would need to. On the downside each element requires a next and previous reference along with the data itself plus you do not get O(1) access to elements and this in itself may be a major downside – depending upon your app.

List<T>

The List is in essence this is a generic ArrayList but type safe and due to the use of generics is more efficient in performance terms when handling value types which require boxing/unboxing.

ListDictionary

This ListDictionary is a simple IDictionary implementation. It uses a singly linked list and it’s smaller and faster than a Hashtable if the number of elements is 10 or less.

NameValueCollection

Then NameValueCollection is used to store name/value pairs, however unlike say a dictionary, nulls can be used for both name and value.

ObservableCollection<T>

The ObservableCollection provide notifications when items are added to or removed from the collection or when the collection is refreshed. Used a lot with binding due to the support for INotifyPropertyChanged and INotifyCollectionChanged.

OrderedDictionary

The OrderedDictionary represents key/value data where the data may be accessed via the key or the index.

Queue<T>

A Queue is a FIFO collection. Whereby items are added to the back of the queue (using Enqueue) and taken from the front of the Queue using (Dequeue). A queue ultimately stores it’s elements in an array.

ReadOnlyCollection<T>

The ReadOnlyCollection class is for a generic read-only/immutable collection.

ReadOnlyDictionary<TKey, TValue>

The ReadOnlyDictionary is a class for generic key/value pairs in a read-only/immutable dictionary.

ReadOnlyObservableCollection<T>

The ReadOnlyObservableCollection is a class for a generic read-only/immutable observable collection. Changed may be made to the underlying observable collection but not to the ReadOnlyObservableCollection wrapper.

SortedDictionary<T>

The SortedDictionary is a dictionary where items are sorted on the key.

SortedList<TKey, TValue>

The SortedList is a collecion of key/value pairs that are sorted by key. A SortedList uses less memory than a SortedDictionary, but the SortedDictionary has faster insertion and removal of items.

SortedSet<T>

The SortedSet is a collection where items are maintained in sorted order. Duplicate items are not allowed.

Stack<T>

The Stack is standard LIFO (last-in first-out) collection. Items are pushed onto the top of the Stack and popped off of the top of the stack.

StringCollection

The StringCollection is a specialization of a standard collection for handling strings.

StringDictionary

The StringDictionary is a specialization of a standard dictionary for handling strings.

SynchronizedCollection<T>

The SynchronizedCollection is a thread-safe collection. It’s part of the System.ServiceModel assembly and used within WCF.

SynchronizedKeyedCollection<TKey, TValue>

The SynchronizedKeyedCollection is a thread-safe key/value type collection. It’s abstract, so is designed to be overloaded for your specific needs. . It’s part of the System.ServiceModel assembly and used within WCF.

SynchronizedReadOnlyCollection<T>

The SynchronizedReadOnlyCollection is a thread-safe read-only collection. This is part of the System.ServiceModel assembly.