Already off to a good start! I started reading the tome this morning on the train to work. I’m tracking all my personal notes through Evernote, so I may share those down the road a bit.
There are things I’m already aware that the CLR does, but they’ll be included if I read about them and I think they’re interesting. For example, I already knew that all exes/dlls get a Windows PE header (if you’re unfamiliar, check out Corkami’s PE101 – it’s crazy good), but I think it’s interesting none the less. I also found out that there’s a separate PE32+ format for 64-bit platforms.
Metadata is actually compiled into every CLR module, which I was unaware of. This means all type information is baked directly into the module itself. Suddenly the previous black magic underlying .NET Reflector with all of it’s advanced module information and assembly cross-referencing seems obvious. That metadata is also why Visual Studio’s IntelliSense feature is so good. Everything drives off of the module metadata, meaning look ups are super-fast and reflect the actual state of the assembled module.
On that note, this metadata only gets included for managed modules. By default, C++ gets compiled down to native modules, so if you’re writing C++ you lose these metadata benefits. However, you can specify an optional compile-time switch, “/clr”, which will turn said modules into managed code. Very neat.
There’s also a very handy tool called CLRVer.exe that’s included with Visual Studio. To run it, open the Visual Studio Command Prompt. It will list installed versions of the CLR. If you supply “-all” as the first parameter, it will show all programs running under the CLR along with what version they’re using. There are separate versions of the VS command prompt, one for x86 and one for x64. It will only report on assemblies running under that particular address space. It will also exclude any process running under other usernames unless ran as admin (at least that’s the behavior I observed).