In a research paper comparing Microsoft's .NET CLR with Java's virtual machine (i.e. JVM) it was found that the CLR, also known as Common Language Runtime, was unsuitable for executing interpretive languages (rather dynamically typed languages).  The research paper "Stacking them up: a Comparison of Virtual Machines" makes with this assesment:

"The most striking difference is the .NET machine designers seem to have been willing to surrender the option of intepretive execution."

It appears that the CLR is unsuitable for executing interpretive languages, examples of which are JavaScript, Python, Ruby and Scheme.  It comes as no surprise then, that earlier work done to run Python on the CLR lead to dissapointing results:

"The speed of the current system is so low as to render the current implementation useless for anything beyond demonstration purposes."

Microsoft funded this work.  As a comparison JPython, a single developer wrote an implementation of Python for the JVM, in his spare time.  JPython or Jython as it is called today is quite useful for every day purposes.

So, this seems that this is a classic case of premature optimization, Microsoft in its need to provide a fast virtual machine, it has compromised its support for interpetive languages.  You have to wonder whether "Common Language Runtime" is an appropriate name considering that a majority of languages are indeed interpretive.  In fact, Visual Basic 6 is also an interpretive language, and its no surprise then that it isn't supported by .NET.

Finally, this brings up alot of new questions about Microsoft's submission of the CLR( rather CLI) to the ECMA standards body.  First of all, clearly the CLR is not as "common" as we may have meant to believe.  Second, Microsoft continues to change the IL at a whim, just look at the proposed generics addition to C# . 

The future of software development will move more towards loosely coupled systems*.  Interpretive languages with late binding and dynamic typing are best suited for gluing these systems together, unfortunately Microsoft has taken the wrong fork on the road on this issue.

*also read "Are scripting languages the wave of the future?""