So I have been thinking about C# lately. C# was born together with .Net and it is commonly thought of as a language that - having little legacy of its own - exposes most of CLR capabilities in a safe and consistent way. Sure, Managed C++ extensions let you do a bit more with IJW and such - but then again, IJW was specifically designed for MC++ and is there to make migration easier.

Overall the perception seems to be that C# is the "clean slate" .Net language - lean, clean and gives you all you need... Most samples you can find out there are in C#, and I have heard plenty of stories involving companies that switched from VB or J++/Java directly to C# despite the fact that VB.Net and JSharp.Net are available.

This is probably for the best - as I was saying before, C# has no legacy of its own so it is thought to have been designed so that no ugly tricks would be needed to translate language contracts into CLR execution primitives. That's probably true.

What is also true, is that things are not quite that simple. There are things that CLR can do - safe, non-ugly things - that C #doesn't expose.  There are things that C# exposes, which CLR is completely unaware of. And it just so happened that lately I have come across a bunch of examples of those things.

So I decided to start as series of posts that look into those things - C# syntax, constructs and capabilities and what they really translate into as far as CLR is concerned.

I'll probably start with simple stuff - like method arguments and delegates - and then just see where that goes.

My methodology is going to be pretty simple - in most cases I'll be writing some C# code, compiling it and "cracking" it open with ILDASM (IL Disassembler that ships with Microsoft.Net SDK) and see what things will translate into... and then speculate on the findings of course :) I definitely don't expect that people reading this will have any deep intimate knowledge of IL - I don't have that myself - but I'll do my best to make the results self-explanatory.

All my findings are based on a particular compiler version - namely one shipped with CLR 1.1 v1.1.4322 (also ships with Vs.Net 2003). While I believe that most things will probably stay they same in future versions as well, that - of course - may not be true.

Stay tuned...