Versions of Microsoft .NET Framework, CLR, and Your Profiler

[Updated 8/13/2008 with the release of Visual Studio 2008 SP1.]

With the many releases of the Microsoft .NET Frameworks and their service packs, it might not be obvious what versions of the Common Language Runtime (CLR) come alongside them and whether your profiler should care.  So I'm posting this to help clarify the various versions.

Note: I'm not talking about the Microsoft .NET Compact Framework or Microsoft .NET Micro Framework in this post.

Check it out!

Before I go any further, I invite you to learn more about the recently released Visual Studio 2008 SP1 and Microsoft .NET Framework 3.5 SP1.  Some great places to start:

Visual Studio 2008 and Microsoft .NET Framework 3.5:

this post from ScottGu's blog, this post from Soma's blog, or directly at the Visual Studio page https://www.microsoft.com/vstudio.

Visual Studio 2008 SP1 and Microsoft .NET Framework 3.5 SP1:

this post from Soma's blog.

Definitions

Ok, so what's the difference between "Common Language Runtime (CLR)" and "Microsoft .NET Framework"?  I think of it as:

CLR + managed libraries and tools = Microsoft .NET Framework

The CLR is the low-level technology (much of it written in unmanaged, native code) that includes the garbage collector, security subsystem, just-in-time compiler, type system, the profiling API (of course :-)), and other similar stuff.  Much of this tends to reside in mscorwks.dll.

If you then add onto that list the many rich managed libraries for implementing graphical user interfaces, web services, accessing Windows OS functionality, etc., as well as the managed language compilers and tools, you get the Microsoft .NET Framework.

Disclaimer: These definitions are how I, geek-Dave, keep things straight in my head. I'm not in marketing so the names I'm using might not be perfectly accurate (e.g., I'm probably missing terms like "SDK" or "redistributable package"). Please don't take these as Microsoft Official Definitions.

Versions

You can get the various Microsoft .NET Framework versions via Windows Update, by searching on https://download.microsoft.com, or by installing the corresponding version of Visual Studio.  Also, Windows Vista comes with Microsoft .NET Framework 3.0 as an optionally installable component.

Here's how the Microsoft .NET Framework versions >= 2.0 correlate with the CLR versions:

Note that the latest CLR version at the time of writing this post is CLR 2.0 SP2 (no such thing as CLR 3.x!).

One exciting note here is that Visual Studio 2008 will actually let you target all three of .NET 2.0, .NET 3.0, and .NET 3.5.

Your Profiler

CLR Versions

Your profiler interacts with the CLR Profiling API, so you likely care which CLR version you're interacting with.  Knowing that the .NET Framework 2.x/3.x versions are all based on CLR 2.x simplifies the picture for you, as you're assured that the profiling API remains compatible across those versions.  However, it's fair to expect that CLR service packs might bring small changes or bug fixes.  CLR 2.0 SP1, for example, contains the following profiling API fixes:

• SetEnterLeaveFunctionHooks2 returned E_INVALIDARG if any of the specified callback pointers were NULL.  For example, one might wish to specify an Enter probe (non-NULL) but not specify a Leave probe (NULL); this was disallowed.  Fix: SetEnterLeaveFunctionHooks2 now allows one or more of the callback parameters to be NULL.
• Various fixes around IMethodMalloc::Alloc
• When a profiler was monitoring Leave calls in order to inspect non-primitive, value-type return values, the profiling API would sometimes specify an invalid value.  This has been fixed.  (More info about this bug was posted here and here.)

CLR 2.0 SP2 had no fixes or changes of note in the profiling API.

Microsoft .NET Framework Versions

Your profiler may also (optionally) take dependencies on the libraries.  For example, if you have an instrumenting profiler that performs IL rewriting on some framework library code, then your profiler should deal gracefully with the cases that the libraries themselves may be different in the various .NET Framework versions.  Other than that, your profiler probably doesn't need to care which version of the libraries is in use.

Long Story Short

Although there are several Microsoft .NET Framework versions out there, your CLR 2.x-based profiler should still be fine.  Of course, the CLR is under active development (those libraries teams aren't the only ones having fun), so look forward to exciting things for your profiler to take advantage of in the future.