Common Language Infrastructure, Runtime, Type System and other C-s
Chronicles of .NET runtime - Part 9
I finally did it :) Honestly, If you’ve been following the CLR series from the beginning, you likely learned that I struggled to figure out all the C-s that are being thrown around. CLI, CIL, CLR, CTS, CLS … out of nowhere VES shows up … hell! It’s one C too many!
Well, I think I finally have it nailed down, so let’s talk about it now.
If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.
I hope you found that useful? If not - well, at least I really felt relief once I managed to put all of it into an infographic. Woohoo!
Before jumping into the WHAT’s and HOW’s, let me just quickly summarize how we got here in the first place. It all started with the idea of exploring the CLR. Which, to tell you the truth, I was clueless that existed as a concept at all. I knew about C# and .NET, and I was aware it wasn’t compiled to native code, but that was all.
As luck would have it, my manager started talking about CLR and SQL Server, and how the two could be integrated (which, if you didn’t know, is this amazing thing that allows you to run your .NET code back-to-back with SQL Server’s Query Engine). This triggered me to go and learn what CLR is at all. And that’s how this whole series about “Deep dive into CLR” started.
Now here’s the funny thing - there doesn’t seem to be a clear info on anything about the CLR anywhere on Internet. Well, at least not clear enough for somebody whose just trying to learn about it. All the online docs make perfect sense if you know WHAT it is, but if you’re a newcomer - good luck :) So I kept reading about CLR (there’s this great book called “CLR via C#” by Jeffrey Richter) but I also kept finding references to CLR being implementation of CLI.
Thing is - I had no clue what the CLI is. And to make it even funnier - there’s also CIL, which stands for Common Intermediate Language. People might occasionally call it IL or MSIL - Intermediate Language and Microsoft’s Intermediate Language. Perfect for newcomers!
To cut the long story short - I kept searching for a diagram, or anything that would show me the connection between CLR, CLI, CIL, CTS, CLS, etc. But I found nothing. Nil. Void. Which eventually led me to the idea of creating one:
Now this honestly makes me happy because I can finally have a mental image of what is what and what is a subset of what, which is something I’ve been trying to figure out for a while. Let’s start from top and progress towards the bottom.
Common Language Infrastructure (CLI) is an openly available standard, commonly referred to as ECMA-335 standard. You can find it here. It’s a 500+ page long PDF which describes absolutely every possible thing you could imagine. And somebody told me that “first 100 pages should be a necessary read for every .NET developer”.
CLI describes the platform. The unique environment that makes it possible to execute multiple languages on. And yes, that means - C#, VB.NET, F#, Managed C++ (commonly called C++/CLI) and even Python (through IronPython), PHP (through PeachPie) and others. So CLI is a top-level idea which, among other things, defines the following:
The language, commonly called Common Intermediate Language (CIL), but occasionally referred to as Microsoft’s Intermediate Language (MSIL). I wrote extensively about it in this article.
Type System, commonly called Common Type System (CTS), which basically argues how you make some meaning out of your bits. It distinguishes two types of data - value types and references, and builds further from there. Any language that wants to conform to CLI has to take into account the CTS definitions.
VM itself, called Virtual Execution System (VES), which actually executes the Intermediate Language. Interestingly enough, CLR (Common Language Runtime) is just one implementation of VES.
And finally - Metadata, which is that thing that everybody loves, right? The data about the data; or the description of data. Meta data. It’s actually really cool and CLI defines TONS of parameters needed in order to give your data an actual meaning which VES further uses to execute your bytecode. It also, among other things, dictates how the CLI code can be injected into EXE files, making them executable just like it was a native code.
Reasonable question to ask would be — WHY? Why would anyone do this in the first place? And I find the actual definition from ECMA-335 PDF to be a perfect answer here:
The CTS is about integration between languages: using another language’s objects as if they were one’s own.
The objective of the CLI is to make it easier to write components and applications in any language. It does this by defining a standard set of types, by making all components fully selfdescribing, and by providing a high performance common execution environment. This ensures that all CLI-compliant system services and components will be accessible to all CLI-aware languages and tools. In addition, this simplifies deployment of components and applications that use them, all in a way that allows compilers and other tools to leverage the high performance execution environment. The CTS covers, at a high level, the concepts and interactions that make all of this possible.
I think that puts the intent just perfectly - make it possible to have multiple languages, that don’t even have to share the syntax, but which do conform to the same rules - rules of CLI. This way you can, say, write majority of code in C#, but write some specific expressions in F# and just reuse them back in C#. Given that it all compiles to same language, the problem simply boils down to the syntax itself :)
And that’d be about it for this article :) And to tell you the truth - this really takes a huge burden of my back as I’ve been really struggling to put all of this into a perspective. The fact that I finally did do it really makes me happy. And I hope you found it useful! :)
If you enjoyed this article - be mindful that I try to post twice a week. So if you haven’t subscribed already, now’d be a good time to do so:
I’d also appreciate if you share it with your colleagues:
Thanks for reading!