Making sense of Contravariance and Covariance in C# 2.0/4.0

Introduction

In simple words, covariance refers to the fact that you can use a type or one of its descendants when the specific type is expected. Say for the following class hierarchy: Doberman -> Dog -> Animal, where Animal is the root/super parent class. If you had a function

public static Dog ProcessDog(Dog myDog)
{
return new Dog();
}

In all versions of C#,

Dog returnDog = ProcessDog(new Dog()); // is valid
Dog returnDog = ProcessDog(new Doberman()); //is valid
Dog returnDog = ProcessDog(new Animal()); //is INVALID.

The above invalidity confirms the fact that all arguments in C# are covariant.

Similarly,

Dog returnDog = ProcessDog(new Dog()); // is valid
Object returnDog = ProcessDog(new Dog()); // is valid
Doberman returnDog = ProcessDog(new Dog()); // is INVALID.

confirms the fact that all return values are contravariant. As in , you cannot use a child type when the parent type is expected in case of return values. Effectively, every type that goes IN is covariant and everything that comes OUT is contravariant.

Covariance and Contravariance in Generics / C# 2.0 / C# 4.0

In C# 2.0, generic interfaces by themselves did not allow for covariance/contravariance. Say if I had

IEnumerable dogs = new List();
IEnumerable animals;
animals = dogs;//is INVALID

I cannot do a animals = dogs; though it make sense literally - arent dogs animals?!. Though note that you could still assign an instance of dog to a animal variable. Coming to C# 4.0, the above statement animals = dogs; works perfectly fine! Why? How?

To understand this, assume a case where IEnumerable allowed setting the value of an item. ASSUME, if you could do

IEnumerable dogs = new List();
IEnumerable animals;
animals = dogs;
animals[0] = cats[0]; //assume cat type to be descendant of animal type

Accessing dogs[0] would now result in an invalid typecast because you are now trying to cast a cat object as a dog!. Thankfully, IEnumerable does not let you set a value to an item, which makes IEnumerable a perfect candidate for covariance. To make sure animals=dogs statement work in C# 4.0, we need to make sure that IEnumerable does not allow for setting/accepting the generic type as a function argument or directly (which is what we did when we did animals[0] = cats[0]).

In our case, what we need to enforce on IEnumerable is to make sure IEnumerable does not have any function which can accept a instance of T (or its descendant). If we did allow, we are introducing the problem of allowing animals[0] = cats[0] OR allowing for animals.AddItem(cat) (declared perhaps as void AddItem(T item)). If we did not allow this, we can ensure that animals=dogs is valid. (which is what C# 4.0 did)

The idea is this : some generic interfaces do not allow inserting items into their list (like IEnumerable) by default. This makes sure that you cannot actually set a specific item of the list with a casted value. For this kind of generics interfaces, C# 4.0 introduces the concept of in, out keyword.

If you had an interface definition of the below kind:

interface Itest
{
T GetVal();
}

the new 'out' keyword makes sure that the type T is covariant. This effectively means that the type T is forced to be a covariant and cannot be used as an IN variable. Say if you tried to add a new method 'GetNewVal' to the above interface as :

void GetNewVal(T someParam);

The compiler would return an error saying T is covariant as T can be used to return a value ONLY.
Similarly, if you had an interface Itest2 as:

interface Itest2
{
void getval(T another);
}

the 'in' keyword makes sure that T is contravariant such that T can be used as an inbound entity (usually as an argument) only. Effectively, if you try to add a new method 'GetYetAnotherVal' as :

T GetYetAnotherVal(void);

the compiler would return an error.

Within C# 4.0, IEnumerable is declared as :

public interface IEnumerable : IEnumerable
{
IEnumerator GetEnumerator();
}

Note the 'out' keyword indicating that no function within IEnumerable can now accept T as input making sure it is covariant to the type T. Outputs are fine (as in GetEnumerator).

References

1.) http://research.microsoft.com/en-us/um/people/akenn/generics/ECOOP06.pdf
Above paper also at http://research.microsoft.com/pubs/64042/ecoop06.pdf

2.) http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29

Two events and a PG course

Basically three things which could interest a software engineer based out of Bangalore :

1.) Great Indian Developer Summit : Happening on days April 22, 23, 24 appears to be the place to be for any software engineer in the .NET/Web/Java streams. Look forward for talks on upcoming cutting edge technologies.

2.) Like to meet geeky innovators who have taken the turn with their startups ? This is the place to be on June 6th

3.) Would like to pick up an MS in Computer Science by attending a weekend programme ? Check out the 2 year MS Computer Science course for professionals conducted by Christ University.

DES Uploaded to CodePlex

Have uploaded the initial version of my hobby project Distributed Execution System to http://des.codeplex.com/

Check the homepage at http://des.codeplex.com/ for a brief summary of the project.

Boxed & Secured Execution Of a .NET Type

One of the usual needs in an application developers world is to instantiate a .NET type in a boxed/contained/isolated environment with zero impact to the current application process space. How do we do that? This article solves this in an easy manner, adoptable easily.

Usual Solution

The immediate answer is to use an Application Domain - create new application domain and instantiate the type within the new domain. Sounds straight forward. Sadly nope. If you thought the following lines of code would just work, you are mistaken. To reconfirm that it does not work, try unloading the app domain and then deleting the loaded assembly from the windows explorer. It does not let you delete the assembly file. What happened here?

//create the application domain and create an instance of the object
AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
Object executionObject = clientDomain.CreateInstanceAndUnwrap("ABC.Test", "MyTest");

//find the Execute method and call it.
MethodInfo executionMethod = executionObject.GetType().GetMethod("Execute");
returnData = executionMethod.Invoke(executionObject, null);

As the type ABC.Test.MyTest was not a MarshalByRefObject descendant, the type instance gets loaded into the main application domain. Instead if the type ABC.Test.MyTest did descend from MarshalByRefObject, the type would have been instantiated in the 'remote' application domain. Thats the way it is designed.

Easy Way Out

Have a proxy type created in your application which descendants from MarshalByRefObject. Instantiate this object and call a proxy routine on this proxy object which then instantiates the real type. In this way, as the proxy type is already created in the new application domain, the real type too would be created in the new application domain.

AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
try
{
AssemblyLoader _aLoader = (AssemblyLoader)clientDomain.CreateInstanceAndUnwrap("XYZ.Test", "XYZ.Test.AssemblyLoader");
returnData = _aLoader.LoadAndRun("ABC.Test", "MyTest");
}
finally
{
AppDomain.Unload(clientDomain);
}

where AssemblyLoader is defined as an MBR descendant as :

[Serializable]
public class AssemblyLoader : MarshalByRefObject
{
public Object Execute(string assemblyName, string typeName)
{
Assembly _assembly = Assembly.Load(assemblyName);
Type _type =_assembly.GetType(typeName);
MethodInfo _method =_type.GetMethod("Execute");
return _method.Invoke(Activator.CreateInstance(_type), null);
}
}

Using this method, we have made sure that "MyTest" is always instantiated in the new application domain.

Impersonate for Security

All good until now, but how do you make sure the executed code executes under a user supplied account ? Pretty simple if you know how to authenticate a username/password/domain. Sadly, there is no direct way to perform a windows authentication in .NET. Not sure why there isnt a "bool WindowsPrincipal.Authenticate(userName, passWord,domain)" routine ? No clues. We could go the LogonUser route, but it appears it has certain permission issues in NT/2000 basedmachines. Hence, lets write one using the NegotiateStream

public static class SSPIHelper
{
  enum AuthenticationState { Unknown, Success, Failure } ;

  public static WindowsPrincipal LogonUser(NetworkCredential credential)
  {
      string userName, domain, password;

      userName = credential.UserName;
      domain = credential.Domain;
      password = credential.Password;

      TcpListener tcpListener = new TcpListener(IPAddress.Loopback, 0);
      tcpListener.Start();

      WindowsIdentity id = null;
      AuthenticationState authState = AuthenticationState.Unknown;

      IAsyncResult serverResult = tcpListener.BeginAcceptTcpClient(delegate(IAsyncResult asyncResult)
      {
          using (NegotiateStream serverSide = new NegotiateStream(
                   tcpListener.EndAcceptTcpClient(asyncResult).GetStream()))
          {
              try
              {
                  serverSide.AuthenticateAsServer(CredentialCache.DefaultNetworkCredentials,
                       ProtectionLevel.None, TokenImpersonationLevel.Impersonation);
                  id = (WindowsIdentity)serverSide.RemoteIdentity;
                  authState = AuthenticationState.Success;
              }
              catch (Exception e)
              {
                  authState = AuthenticationState.Failure;
              }
          }
      }, null);


      using (NegotiateStream clientSide = new NegotiateStream(new TcpClient("localhost",
                   ((IPEndPoint)tcpListener.LocalEndpoint).Port).GetStream()))
      {
          try
          {
              clientSide.AuthenticateAsClient(new NetworkCredential(userName, password, domain),
                       "", ProtectionLevel.None, TokenImpersonationLevel.Impersonation);
              authState = AuthenticationState.Success;
          }
          catch (Exception E)
          {
              authState = AuthenticationState.Failure;
          }
      }

      while (authState == AuthenticationState.Unknown) ;

      tcpListener.Stop();
      if (authState == AuthenticationState.Success)
          return new WindowsPrincipal(id);
      else
          return null;
  }
}

Ok, we have a windows principal. Now what ? Impersonate to execute the code using this principal, which happens to be the easy bit.

WindowsIdentity newId = (WindowsIdentity)windowsPrincipal.Identity; //the one received from SSPIHelper
WindowsImpersonationContext impersonatedUser = newId.Impersonate();

This makes sure that the code following the above Impersonate() call uses the provided identity. Once we want to revert back to the original identity, just do a Undo() (see below)

So effectively what we now have is an isolated and safe execution of a type provided by the client using the credentials supplied by them. To summarize, the code should look similar to this:

//authenticate the client supplied credentials
WindowsPrincipal windowsPrincipal = SSPIHelper.LogonUser(credentials);
WindowsIdentity newId = (WindowsIdentity)windowsPrincipal.Identity;

//impersonate
WindowsImpersonationContext impersonatedUser = newId.Impersonate();
try
{
//create the application domain and create an instance of the object
AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
try
{
 //use the proxy MBR object
 AssemblyLoader _aLoader = (AssemblyLoader)clientDomain.CreateInstanceAndUnwrap("XYZ.Test", "XYZ.Test.AssemblyLoader");
 returnData = _aLoader.LoadAndRun("ABC.Test", "MyTest");//call the client's method
}
finally
{
 AppDomain.Unload(clientDomain);
}
}
finally
{
impersonatedUser.Undo();//back to the normal a/c
File.Delete(assemblySaveLocation);//just to clean up things, clean the client's assembly too.
}

Chrome crashed

In fact I thought Chrome would never crash when one of the tab got screwed since there was this concept of each tab executing within a different process.  A behaviour easily verified by browsing to about:memory and cross checking the PID with the windows process ID.

Sadly this near perfect browser crashed today :(

Should have noted down the steps that caused this. Have now enabled chrome to generate crash dumps as detailed here

While you are here, also check out chrome's process model here

WCF Service and a SilverLight 2 beta 2 Application

While trying to call a simple WCF service from a silverlight application, not everything goes smoothly from within VS 2008. Though coding itself did not take more than half an hour, to hack the stuff to work good took me around a day.

You would usually require to get past the following hurdle's:

1.) The default binding for the WCF service appears to be secured - wsHttpBinding, which is not currently supported by silverlight. This mean editing the web.config to use basicHttpBinding instead.

2.) Even if the WCF service project and the silverlight application is in the same solution, you would not be able to call the WCF service directly since silverlight does not support cross-domain calls. This appears to be a security check from the silverlight end. To get past this, you would have to specify that both the project (WCF and the silverlight host web application) to use the same virtual directory from the project properties (check the 'Use IIS Web Server' under project properties, web tab). 

In my case, I used "http://localhost/NumberService" for the WCF service and "http://localhost/SilverLightApplication1Web" for the web application.

The above changes should get the silverlight to successfully call the WCF service from within the VS 2008 IDE. Incase you still get cross-domain errors say when your WCF service is on a different host, host the web applications directly under IIS and make sure you have created a 'clientaccesspolicy.xml' file in the root of the virtual directory with the following content :

<?xml version="1.0" encoding="utf-8"?>

<access-policy>

  <cross-domain-access>

    <policy>

      <allow-from http-request-headers="*">

        <domain uri="*"/>

      </allow-from>

      <grant-to>

        <resource path="/" include-subpaths="true"/>

      </grant-to>

    </policy>

  </cross-domain-access>

</access-policy>

The above bit just makes sure that cross domain access is allowed from all URLs (check out the allow-from tag). I could not get this to work while debugging from within the VS IDE though.

If you are still having trouble making cross domain calls, the easiest option is to create a proxy webservice within the same domain as the web application. This proxy webservice can make the actual call to the webservice on a different domain.

3.) When trying to host the silverlight web application under IIS, you might get an IIS error about unknown MIME type 'xap'. In this case, just create a new entry under the MIME types within IIS for 'xap' as 'application/x-silverlight-2-b2'

4.) Strangely, once you have setup the above two projects, VS 2008 fails to load later when you try to reload the solution. It fails with a System.Runtime.InteropServices.COMException each time. The only way to get past this while making sure that the solution loads good is to load VS 2008 under the administrator credentials. From Vista, right click on the VS 2008 shortcut and click on 'Run As Administrator'

Further Silverlight Notes:

1.) Starting Silverlight 2 beta 2, It is quite easy to get a simple timer to work under Silverlight 2 beta 2. Just use the System.Windows.Threading.DispatcherTimer class.

2.) All calls to the WCF service is by default async. The service reference within the silverlight application always generates an async reference (the one with the 'Async' suffic to the method)

Bounce that spam please!

Looking at the number of spam emails (approximately 3 spams for 1 good email!), something needs to make sure that the same sender does not send a different spam. To handle this, we could have an auto-bounce feature such that once a spam is marked manually for auto-bounce, the next spam from the same user results in an 'invalid email-address' or 'inbox full' kind of messages.

The only issues we might face:

1.) This involves the mix-up of user-requirement with the underlying protocol!. No purists would like this.

2.) The spam-generators would start getting intelligent in sending spams - It might start using different 'from' addresses and messages against the same Inbox. If either of the email was delivered, it can safely assume that the email-id is valid. This could be resolved by letting the email-server perform auto-bounce using the same logic it uses currently for spam, rather than explicitly marking it for an 'auto-bounce'.

3.) In cases of the server automatically handling it, we might loose a couple of good emails since it was identified as spam and got auto-bounced.

Can this work ? How else can I avoid that spam from reaching my email box and avoid skimming through the hundreds of spam in search of that one good-email ?