The Evolution of Generics in C# 4.0

Before I begin, let me point out that I'm primarily writing this post to solidify my own understanding of the new generic structures and put it into my own words, there are already some great posts that already explain this in much greater depth and detail: (Generic Variance in C# 4.0 by Discord & Rhyme, What's the difference between covariance and assignment compatibility? By Eric Lippert)

So that being said, let start off with the problem that generics solve in the first place. (If you have a good understanding, you can jump to the new features in C# 4.0)

C# Prior to 2.0

Lets say I have the following class hierarchy:

  1. public abstract class Fruit { }
  2.  
  3. public class Apple : Fruit { }
  4.  
  5. public class Orange : Fruit { }
  6.  
  7. public class FruitBasket
  8. {
  9. public Fruit[] Fruit { get; set; }
  10. }
  11.  
  12. public class Tree
  13. {
  14. public Fruit[] PickFruit()
  15. {
  16. Fruit[] daFruit = new Fruit[2];
  17. daFruit[0] = new Apple();
  18. daFruit[1] = new Orange();
  19. return daFruit;
  20. }
  21. }

We have a hierarchy of objects, a base Fruit class, an Apple class, which is a Fruit, and an Orange class, which is also a Fruit. In addition, we have a FruitBasket which has an enumerable of Fruit, and a Tree which I can "PickFruit()" from.

Now, lets say I want to have an instance of a fruit basket, however, I also want another one that deals with only Oranges (I don't want it to even be possible to put apples in the basket) so that I can make orange juice, apples just ruin a good glass of orange juice. I have two possibilities, I can create another fruit basket and ASSUME that I only put oranges in, or I create another classes that only allows oranges to be inserted in. Because I decide that I want the compiler to absolutely not allow apples in with the oranges, I now have to create a new class:

  1. public class OrangeBasket
  2. {
  3. public Oranges[] Oranges { get; set; }
  4. }

Or if I now want to have a basket that holds potatoes, I have to build another class:

  1. public class PotatoBasket
  2. {
  3. public Potato[] Potatos { get; set; }
  4. }

Right. Pattern. We are repeatedly creating virtually identical objects that simply contain other objects or that apply some sort of processing to those specific elements, all because we want the consumer (the person that is using this object) to be able to put an specifically typed object in and get a specifically typed object out, without having to cast it.

C# 2.0 - 3.5

With the release of C# 2.0 Microsoft introduced this concept of "generics" in programming. It allows programmers to create generalized algorithms that take and receive specific objects, store or process them, and return them, without knowing the creator of the object being worked on or knowing specific type. C# 2.0 also included a number of generic collections and interfaces that implemented these features, the most useful in my mind being the generic IEnumerable<T> interface. This now allows us to rewrite our basket class like follows:

  1. public class Basket<T>
  2. {
  3. IEnumerable<T> Contents{ get; set; }
  4. }

Now, instead of having a PotatoBasket, a FruitBasket, and a OrangeBasket we can replace it like so while still using the same class:

  1. Basket<Potato>
  2. Basket<Fruit>
  3. Basket<Orange>

And our Tree class now becomes:

  1. public class Tree
  2. {
  3. public IEnumerable<Fruit> PickFruit()
  4. {
  5. yield return new Apple();
  6. yield return new Orange();
  7. }
  8. }

So now, we have a Basket of Potatos, a Basket of Fruit, and a Basket of Oranges. Yet, we didn't have to duplicate the classes, and any the implementations still preserves type safety.

This is where it gets… Interesting.

Lets say I have an instance of a Tree class, and an instance of my Basket<Fruit> class. Now, it’s simple to do an assignment like this:

  1. var fruitBasket = new Basket<Fruit>();
  2. var Tree = new Tree();
  3. fruitBasket.Contents = tree.PickFruit();

BUT if I have a tree that has a PickApples() method like this:

  1. public IEnumerable<Apples> PickApples()
  2. {
  3. yield return new Apple();
  4. yield return new Apple();
  5. yield return new Apple();
  6. }

And I attempt to do the same assignment as before but with the PickApples() method instead, C# 3.5 will not compile it because the generic parameters are not the same:

  1. var fruitBasket = new Basket<Fruit>();
  2. var Tree = new Tree();
  3. fruitBasket.Contents = tree.PickApples();

That sucks. Why?

The reason has to do with the relationships of types, covariance / contra-variance / invariance (Erick Lipperts post on the difference between covariance and assignment compatibility is a much better source for it's relation with mathematics and type hierarchies). With versions prior to 4.0 the C# compiler does NOT allow generics of one type to be assigned to generics of another type. Thus, an IEnumerable<Apple> cannot be assigned to a variable of IEnumerable<Fruit>. But lets say we were allowed to do this, why would it be a problem? Lets say I have an IList<Fruit> and an IList<Apple>; it seems to make perfect sense that I could so the following assignment:

  1. var fruitList = new List<Fruit>();
  2. var appleList = new List<Apple>();
  3. fruitList = appleList;

Right?

Wrong.

This assignment would actually be plausable for IEnumerable<T> because IEnumerable<T> is immutable, it can not change, there's no way to "Insert" a new element into an IEnumerable. However, with an IList<T> it defines an Add(T item) method. An IList can be altered. In the previous example, if I were to take fruitList and look at the Add method in intellisense, it would show that I can insert any object that is a fruit into the add method of the fruitList, however, fruitlist isn't technically a list of fruits anymore given this senario, its a pointer to a List<Apple>. So in this flawed example, I could now call fruitList.Add(new Orange()); which would now be a runtime error because I can't insert an Orange into a List<Apple>. Bad. (In C# however, there is an edge case where this sort of error can occur with arrays. For instance, if you have a object[] objarray = new string[10]; you can then assign a fruit to one of the slots and cause a runtime exception. For more detail on this, see Erick Lipperts post on Covariance and Contravariance in C# arrays) So we have two things that should be solved. We know that there are certain situations where IEnumerable<X> should be assignable to IEnumerable<T>, specifically when X is a subclass of T, but we also realize that something like IList<X> should not be assignable to a variable of IList<T>.

C# 4.0

Enter variance modifiers for generic types that have now been introduced in C# 4.0.

out and in.

First, these can only be applied to generic type parameters of interfaces and delegates, in can only be applied to generic parameters that are contra-variant or invariant valid, and out can only be applied to generic parameters that are co-variant or invariant valid.

Gulp.

First, invariance, contra-variance, and covariance. In terms of types, if I have T1 and T2, those types are Invariant if they are the same type. For instance, a Fruit and a Fruit are invariant, a Fruit and an Apple is not invariant even though a Fruit variable can hold an Apple object.

Co-variant is where the inheritance chains are kept, if I have T1 and T2, the projection of T1 to T2 is covariant if T2 is lower in the inheritance chain than T1. For instance, a Fruit to Apple is Co-variant because Apple is an instance of Fruit.

Contra-variant is where the inheritance chain is reversed, if I have T1 and T2, the projection of T1 to T2 is contra-variant if T2 is higher up the inheritance chain than T1. For instance, an Apple to Fruit is contra-variant because Apple is an instance of Fruit, the relationship is reversed, flipped.

So, it allows me to do the following in C# 4.0 with the new variant structure:

  1. var fruitBasket = new Basket<Fruit>();
  2. var Tree = new Tree();
  3. fruitBasket.Contents = tree.PickApples();

Because IEnumerable is defined as follows:

  1. IEnumerable<out T> { /* .. */ }

Remembering that out is co-variant because it can return the item or a subclass of that item, in this case PickApples() is returning an IEnumerable that is lower in the inheritance chain than the variable it's being assigned to (by lower, I mean that its a subclass, or sub-sub..n class of the other object)

To demonstrate a class with contra-variance with an in parameter, lets say we have an interface and classes like so:

  1. IPieMaker<in T> where T : Fruit
  2. {
  3. Pie MakePie(IEnumerable<T> fruits);
  4. }
  5.  
  6. ApplePieMaker : IPieMaker<Apple> { /* ... Some implementation ...*/ }
  7. FruitPieMaker : IPieMaker<Fruit> { /* ... Some implementation ...*/ }

Now, because the input parameter is contra-variant, I can have a variable declaration like so:

  1. IPieMaker<Apple> applePieMaker = new FruitPieMaker();

Wait. Seem odd? Because T is not specifying what Pie we are making only what is put IN to make the pie, I can put apples into a FruitPieMaker. It’s contra-variant.

Try and wrap you head around that :)

Note: There's a good possibility that I didn't accurately describe the terms covariance and contra-variance in relation to mathematical projection and ordering, corrections and better descriptions are greatly appreciated.

Additional Links:

Building a REALLY simple WCF P2P application

Often times when I’m looking at playing with a new technology that it becomes extremely difficult to find a simple stripped down easy-to-use chunk of code that also walks through, in-depth, the concepts and reasoning behind the code. This particular code chunk began as I started exploring the Microsoft WCF’s P2P networking services and found a rather distinct lack of code that explained the hows and whys of building a Peer to Peer network.

P2P Basics

Ok. Low level building blocks.

First, everybody (who’s interested in P2P) should already understand the client server paradigm, if not, there are many wonderfully detailed articles to explain the details. In short we have N clients all connected to 1 server. Client A sends a message to the server, the server decides what to do, and then may or may not send a response to Client A and / or Client B, Client C… etc… In a peer to peer network on the other hand, everyone is the client, everyone is a server. Because of this, the client / server naming scheme goes away by popular vote and everyone is called a node or a peer. When a node is connected to other nodes that whole group is called a mesh (or graph, or cloud).

Now, in a pure P2P network there is no central authority to help or govern how nodes find each other to form a mesh or how meshes are initially created.  Every node is connected to some number of other nodes, which are then connected to more nodes and so on. When one node wishes to communicate with another node (or nodes) the message is first passed on to the nodes that the first node knows about. These nodes in turn pass along the message on to other nodes that they know about and so on until finally everybody has seen the message.

One of the best, and probably most used, examples of a peer to peer network is the chat room. Until someone creates it, the chat room does not exist, but once it’s created people can be invited, join, and send messages that appear on everybody else’s screen. Even if the original person leaves the chat room, the room still exists as long as there are participants logged in. Once the last person leaves the chat room no longer exists.

Ping – The P2P Application

Note: I really dislike configuration files in demos or tutorials unless it’s a large application or showing how a particular aspect of a configuration file works. The fact that I can tell a static factory to build me something with a string name that corresponds to another file that somehow gets found, loaded, and happens to reference compiled type that then has a hidden class generated that implements that interface and is passed, bugs me when I’m trying to learn something.

If your going to follow along with this, your going to need .NET 3.5 installed and be running XP SP3, Vista, Win7 or Server 08. Visual Studio doesn’t hurt either.

To set up your project crack open Visual Studio and spin up a new Console Application, call it SimpleP2PExample. Once you have that open go over to the project, right click and Add Service Reference to System.ServiceModel, this allows you to use .NET’s WCF stuff in your app. You can choose to split up each class or interface into its own file or not: Up to you.

IPing
  1. //Contract for our network. It says we can 'ping'
  2. [ServiceContract(CallbackContract = typeof(IPing))]
  3. public interface IPing
  4. {
  5. [OperationContract(IsOneWay = true)]
  6. void Ping(string sender, string message);
  7. }

Alright, first of all, attributes. If you don’t know what they are, then here’s the low down mouthful one line explanation:

Attributes are essentially binary metadata associated with a class, method, property or whatever that provides additional information about whatever it’s “Decorating”.

The first attribute is the service contract. Wait a second. Contracts.

In our node-talking-to-other-nodes scenario, somehow they have to know how to talk to each other, if I asked what the size of the door was and you handed me a window, I have NO idea what that means or what that represents. A contract defines exactly what I’m telling you, what I’m expecting back, how, and when.

In this case we’re defining a contract that has one operation, a method called Ping. We know that when node A talks to node B that if node A says “Hey, Ping(“MyName”, “Hello.”) to Node B that node B will know what to do with that and how to pass it along to other nodes. It’s also specifies that I don’t expect Node B to give me anything back.

Now, the implementation.

PingImplementation
  1. //implementation of our ping class
  2. public class PingImplementation : IPing
  3. {
  4. public void Ping(string sender, string message)
  5. {
  6. Console.WriteLine("{0} says: {1}", sender, message);
  7. }
  8. }

Fairly simple, whenever we receive a ping from another node, this method will be executed.

The Peer Class

Alright, now the fun, magic, and games begin. We’re going to create a class called peer, which will contain all our service start / stop code and also hold our implementation of PingImplementation.

Peer
  1. public class Peer
  2. {
  3. public string Id { get; private set; }
  4.  
  5. public IPing Channel;
  6. public IPing Host;
  7.  
  8. public Peer(string id)
  9. {
  10. Id = id;
  11. }
  12. }

In order to identify an individual node in the network, so that we know who’s who and don’t get everything mixed up, it’s customary to have a unique Id that’s assigned to the peer. Now, we have two IPing variables, the best way to describe them would be incoming and outgoing. An instance of the PingImplementation class will go in Host since it will be receiving any incoming communication from other nodes; The Channel is used to communicate out to other nodes and is built up via a factory.

Peer
  1. public void StartService()
  2. {
  3. var binding = new NetPeerTcpBinding();
  4. binding.Security.Mode = SecurityMode.None;
  5.  
  6. var endpoint = new ServiceEndpoint(
  7. ContractDescription.GetContract(typeof(IPing)),
  8. binding,
  9. new EndpointAddress("net.p2p://SimpleP2P"));
  10.  
  11. Host = new PingImplementation();
  12.  
  13. _factory = new DuplexChannelFactory(
  14. new InstanceContext(Host),
  15. endpoint);
  16.  
  17. var channel = _factory.CreateChannel();
  18.  
  19. ((ICommunicationObject)channel).Open();
  20.  
  21. // wait until after the channel is open to allow access.
  22. Channel = channel;
  23. }
  24. private DuplexChannelFactory<IPing>; _factory;

This is what we will use to start the peer.  This is the part where I’ve built up what could have been done in the configuration file with code instead.

Lets take it from the top.  First off, we have our binding; this defines what communication protocol we are going to be using, and as this is a PeerToPeer app… we use NetPeerTcpBinding().  You’ll also notice that in the next line I set the security mode to none; this is done for simplicities sake. There’s three types of security modes, including None, Message, Transport and TransportWithMessageCredential. Its a bit beyond the scope of this post, but Message security ensures that the message was not tampered with as it was passed from peer to peer, Transport security ensures that the connection between nodes is secure, and TransportWithMessageCredential does both.

Now, our application needs an endpoint, essentially, an service endpoint is a set of information that is exposed outside of the application (in this case on the network as well) so that others can access it. The endpoint defines the address it can be reached at, the contract, and the method that should be used to communicate. In this case, we build up our endpoint by using ContractDescription.GetContract to generate a contract class off of our IPing interface, our network type binding, and an endpoint address where this endpoint can be reached.

Finally, we create a new instance of our PingImplementation class as the Host, and we create our channel factory. A DuplexChannelFactory allows for two way communication, the first parameter is the object that you want to receive incoming calls, and the endpoint is where those calls are coming from. The factory then creates the channel and a whole bunch of magical things happen.

If you’ll remember, our channel is of type IPing, the Duplex Factory performs some magic and generates a concrete implementation of your interface (it also implements ICommunicationObject, which is why you’ll sometimes see people create another interface called something like “IPingChannel : IPing, ICommunicationObject”, it does make it so that you don’t have to cast it, but for the purpose of this post it’s not necessary). Imagine that it takes your interface, implements all the methods and properties with all the cool DuplexChannel code needed to talk back and fourth, creates an instance, and returns it to you.

Finally, I call open on my channel to let the world see that my brand new channel and endpoint are ready for business.

Peer
  1. public void StopService()
  2. {
  3. ((ICommunicationObject)Channel).Close();
  4. if (_factory != null)
  5. _factory.Close();
  6. }

Now, it’s all well and good, until your done. Then you need to close you channel and factory, this should be pretty self explanatory at this point.  Remember our channel is an ICommunicationObject in addition to being a IPing object, so we cast and close, then check to see if our factory is null, and if not, close that as well.

Threading The Peer Class

Something I chose to do was make the peer threaded. This allows me to drop it into an application, in a thread, and receive and push stuff into it at my leisure. To do this I add in a:

Peer
  1. private readonly AutoResetEvent _stopFlag = new AutoResetEvent(false);

This will allow me to block a method of the thread until I decide fire it (When I stop the peer).

Peer
  1. public void Run()
  2. {
  3. Console.WriteLine("[ Starting Service ]");
  4. StartService();
  5.  
  6. Console.WriteLine("[ Service Started ]");
  7. _stopFlag.WaitOne();
  8.  
  9. Console.WriteLine("[ Stopping Service ]");
  10. StopService();
  11.  
  12. Console.WriteLine("[ Service Stopped ]");
  13. }
  14.  
  15. public void Stop()
  16. {
  17. _stopFlag.Set();
  18. }

The run method embodies the lifecycle of this peer. When the peer thread starts into the run method it will start the service, wait until the stop flag is fired (when the Stop() method is called), and then stop and dispose the service.

Putting It All Together
Program
  1. class Program
  2. {
  3. static void Main(string[] args)
  4. {
  5. if (Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName).Count() <= 1)
  6. {
  7. for (int i = 0; i < 4; i++)
  8. {
  9. Process.Start("SimpleP2PExample.exe");
  10. }
  11. }
  12.  
  13. new Program().Run();
  14. }
  15.  
  16. public void Run()
  17. {
  18. Console.WriteLine("Starting the simple P2P demo.");
  19.  
  20. var peer = new Peer("Peer(" + Guid.NewGuid() + ")");
  21. var peerThread = new Thread(peer.Run) {IsBackground = true};
  22. peerThread.Start();
  23.  
  24. //wait for the server to start up.
  25. Thread.Sleep(1000);
  26.  
  27. while (true)
  28. {
  29. Console.Write("Enter Something: ");
  30. string tmp = Console.ReadLine();
  31.  
  32. if (tmp == "") break;
  33.  
  34. peer.Channel.Ping(peer.Id, tmp);
  35. }
  36.  
  37. peer.Stop();
  38. peerThread.Join();
  39. }
  40. }

From top to bottom, the Main method of the application checks to see if it’s the first one of this application to have started up, if it its, then it starts four additional processes (Note that if you called your project something other than SimpleP2PExample, you will need to replace the the string in Process.Start to be the name as the executable file your project generates).

The run method is also fairly simple, it creates a new instance of the Peer class, assigns it a GUID, creates a thread for the peer’s run method, starts up the thread and pauses to wait for the peer’s thread to start.  We then enter a loop until the user presses enter without inputting any text. Any text that is put in is transmitted over the peer channel using the peer’s id and the message. Once we’ve finished, we stop the session and wait for the peerThread to exit and join back up with the main thread. We then exit.

Wrap Up

I hope this helps someone out there get a better understanding of the basic concepts of a simple Peer to Peer application. Feel free to leave feedback!

Paul Rohde

Timesheet App + 3rd Place = $100

For those of you that read this blog… And saw my previous post about peak… I entered a timesheet application that I had written for human computer interface design class and ended up with 3rd place! Even so I was quite surprised at the level of interest in the application by some of the faculty and several students who have part time jobs here at Neumont.

The project started off as solution to a problem: How to get people who are paid on a per hour basis and who have their own development machine, to keep accurate timesheets.

I know that people have trouble remembering to consistently fill out a timesheet every day and for every break, it’s not a problem with the person themselves, but just that people are not perfect and do forget things from time to time. Currently, there are two methods of keeping track of time: One is simply to fill out a form every day (or excel document, or some form of tabular information) listing off the time you came in and the time you left, and then totaling the time on the form to get a total time. The second is a ‘clock in’ and ‘clock out’ program where you will either log in or have some form of clicking ‘start timer’ and ‘stop timer’. Some way’s are combinations of all of the above.

I wanted an application that was so simple to use, so unobtrusive that you would hardly even notice you were using it, and something that would keep a detailed record of my activity. I started out with the basic assumption that when a person was active on their computer that they were ‘working’ and that if they left for more than say, 10 minutes that they were ‘not working’. That being said, I quickly realized that there would always be exceptions to this, an hour long meeting, an extended time discussing or planning out a project on a white board… etc. So at the very beginning of the project I knew I need to have a simple, unobtrusive, way to handle exceptions to the normal workflow during the day.

[ This next section gets technical ]

The base of the application relied on hooking into the global mouse and keyboard events via Win32 DLL’s so that I was able to determine when a user is active on their computer. The application disappears into the system tray and keeps a running variable of the last time an action was performed. When a new action is performed it compares the time the new action was performed the previous action. If the difference is greater than a specified period of time (Which is stored in the application settings) the application pops up a message box to the user and asks them if they were working or not and provided an space to enter an optional comment. It then creates two time period segments, the first is for the time they were active up until the start of the activity gap, the second is from the start of the activity gap to the end of the activity gap. It then saves the timesheet and disappears again.

[ End technical section ]

The essence of this program is that it only asks ‘were you working?’ when you’ve been inactive from your computer during your specified working hours. Otherwise you would never even notice that the application existed. For me it’s perfect because it’s something that’s unobtrusive enough that I could run it on startup and just forget about it. It’s detailed because it asks you about exceptions, and it’s robust and stable.

Something that I was really intrigued by was the verity of ideas and features that people wanted for different things. If I decide to continue working on this (which I may) there are several core features that I still need to add. After that, I am thinking that I’ll add ‘aspects’ to the program; an aspect being not a ‘re-skinning’ but a re-skin plus additional functionality. For instance, one of the big ideas was being able to track application usage and to be able to record which applications were being used for how long and at what time. Another was the ability to categorize their time use. A third was the ability to have multiple users working on the same computer. I’m still going to have to work a lot of these issues out and figure out what’s going to be in the core project and what’s going to be included in the various ‘aspects’ of the program.

It’s an interesting project, and I’ll probably keep playing with it and adding additional functionality and ideas. If you’re interested in it, let me know, get in touch, suggest ideas. Who knows… maybe I’ll let you beta test ;)