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

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);
}

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.

The dynamic keyword was added to C# in .NET 4.0. It was probably primarily added to .NET to support interop with languages such as IronPython, also to aid in interop with COM objects and for handling anonymous types.

What’s a dynamic variable ?

A dynamic variable is not statically typed and can be assigned any type (just like an object) however we can write code that interacts with the type even though we might not know what the type looks like – in other words it’s late bound. What this really means is that we can interact methods, properties etc. even though we might not have the actual type to compile against. Our code will compile correctly even without the known type, due to the dynamic keyword but errors may occur at runtime if the actual type does not have the expected methods, properties etc. in which case we’ll get a RuntimeBinderException exception.

So to make things a little clearer, let’s assume that we have a factory class which creates an object. We don’t know the actual object type but we do know it has a FirstName property – here’s a contrived example of what the code might look like…

public static class Factory
{
   public static object Create()
   {
      return new Person{FirstName = "Edmund", LastName = "Blackadder"};
   }
}

Now, obviously if we knew the type returned was a Person type, we could cast the return to type Person. But for the sake of argument we’ll assume we do not know what’s being returned, all we know is that it has a FirstName property. So we could create a dynamic variable thus

dynamic p = Factory.Create();
Console.WriteLine(p.FirstName);

Notice, we interact with the FirstName property even though we do not know the type that the dynamic variable represents. As stated, at compile time this works just fine and at runtime this will output the string “Edmund”. However, as also stated previously, say we made a spelling mistake and FirstName became FrstName, this would also compile but at runtime would fail with the RuntimeBinderException exception.

We can also store anonymous types (as mentioned at the start of this post) in a dynamic variable and interact with those type’s properties and methods, for example

dynamic p = new {FirstName="Edmund"};
Console.WriteLine(d.FirstName);

Dynamic dynamic variables

We can also define dynamic behaviour at runtime by defining our own dynamic type. So creating dynamic dynamic types (if you like).

For example, one of the cool features of the CsvProvider in F# is that if we have a CSV file with the first row storing the column headings, when we enumerate over the returned rows of data the object we get back will automatically have properties named after the headings with the row data assigned to them. Note: we cannot, as far as I currently know replicate the F# ability to add to intellisense, but let’s see how we might implement similarly late bound column name properties to a type.

So let’s assume we had the following stock data in a CSV file

Symbol,High,Low,Open,Close
MSFT,37.60,37.30,37.35,37.40
GOOG,1190,1181.38,1189,1188
etc.

We might like to read each line from a CsvReader class, maybe it has a ReadLine() method that returns a CsvData object which can change it’s properties depending upon the heading names in the CSV file.

So to implement this CsvData class by deriving it from the DynamicObject and this will now allow us to dynamically create properties at runtime. This is similar to implementing dynamic proxies.

public class CsvData : DynamicObject
{
   private CsvReader reader;
   
   public CsvData(CsvReader reader)
   {
      this.reader = reader;
   }

   public override bool TryGetMember(GetMemberBinder binder, out object result)
   {
      result = null;

      if(reader.Headers.Contains(binder.Name))
      {
          result = reader.Headers[binder.Name];
          return true;
      }
      return false;
   }
}

So the above code assumes the CsvReader has some collection type from which we can get the headers (and check whether a header name exists).

Basically if we use the following code

CsvReader reader = new CsvReader("stocks.csv");

dynamic stock = reader.ReadLine()
Console.WriteLine(
   String.Format("Symbol {0} High {1} Low {2}", 
      stock.Symbol, stock.High, stock.Low));

we can access properties which are created at runtime.

Obviously if we were to change the CSVReader to read data from a different type of data, maybe something like a list of CD data, for example

Artist,Album,Genre
Alice Cooper,Billion Dollar Babies,Rock
Led Zeppelin,Houses of the Holy,Rock

we can still use the same CsvReader and CsvData code to access the new properties. In this case our dynamic variable will use properties such as cd.Artist, cd.Album, cd.Genre etc.

Dynamics in LINQ

Instead of a ReadLine method on the CsvReader, what if it implemented an IEnumerator interfaces, we could now use the CsvReader with LINQ using the following

CsvReader reader = new CsvReader("stocks.csv");

var data = from dynamic line in reader
               where line.Close > line.Open
                  select line;

foreach(var stock in data)
{
   Console.WriteLine(
      String.Format("Symbol {0} High {1} Low {2}", 
         stock.Symbol, stock.High, stock.Low));
}

Notice the use of the dynamic keyword before the variable line. Without this the line.Close and line.Open will cause a compile time error.

Note: the above example of course assumes that line.Close and line.Open are both numerical values