Enumerating CLR versions

re: Enumerating CLR versions

John Hensley — Sat, 09 Jul 2005 02:51:31 GMT

Great post! Thanks for making this very useful information available. The #defines for RUNTIME_INFO_UPGRADE_VERSION, RUNTIME_INFO_UPGRADE_VERSION and RUNTIME_INFO_DONT_SHOW_ERROR_DIALOG that are passed as the runtimeInfoFlags parameter don't seem to be defined in any of the headers in DevStudio 2003, DevStudio 2005 Beta 2 or current SDKs.

re: Enumerating CLR versions

Ian Thomas — Sat, 09 Jul 2005 13:36:15 GMT

Yeh, the first thing the owner of this code should do is to make it well known to the Windows Installer guys, and to the VS2003 / VS2005 teams, so there's a Custom Action DLL built for the MSIExec, and/or incorporated into the non-dotNET bootstrapper.

The REAL WORLD largely doesn't have ANY version of the CLR installed, or possibly has .NET v1.1; worse, we find that clients have "experimental" installs of this or that beta or CTP, and it's hell's business to sort it out and make something written for v1.1 install and work smoothly.

I don't know if you recall Microsoft's systematically orchestrated chaos that was MDAC data connectivity versioning, but I'd hate to think that you guys think that by providing a little bit of C++ code the transitioning problems for developers and users, for systems going from Win32 to some version of .NET, will be a piece of cake.

Life's tough out here!!

re: Enumerating CLR versions

Andrei Ignat — Sat, 09 Jul 2005 16:02:55 GMT

Great information.
How about an API in next versions of .NET about those version ( reflection, any other code)? Why MUST all this code be written in C++ and not in C# ? ( or any other .NET language )?

Interesting Finds

Jason Haley — Sun, 10 Jul 2005 16:24:49 GMT

Interesting Finds

Jason Haley — Mon, 11 Jul 2005 12:58:16 GMT

re: Enumerating CLR versions

Andy — Mon, 11 Jul 2005 15:05:20 GMT

John - I just did a search for RUNTIME_INFO_UPGRADE_VERSION in my Visual Studio 2005 Beta 2 folder, and I found it in SDK\v2.0\include\mscoree.h. Maybe you should look in the .NET SDK folder instead of the Platform SDK folder?

Andrei - personally, I find these functions much more useful in the unmanaged C++ case than in the C# case. If you're in C# already, then the CLR is already loaded and you can't really do anything about that. From C++, you can make an intelligent decision based on the versions that are installed. I have to do just that, although I'm not sure if I want to rely on the above code though since I'll need to do the same sort of thing even if .NET v2.0 isn't installed, which doesn't have this ability.

You can get the current version of the CLR that is running from C#, just call System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion(). If Microsoft is going to expose the above functionality from within .NET, it would probably be in the RuntimeEnvironment class, which appears to be a wrapper for the unmanaged API exposed by mscoree.dll.

re: Enumerating CLR versions

Anonymous — Mon, 18 Jul 2005 16:57:37 GMT

How about also expanding this code to include displaying information on service packs and hotfixes. The lack of a "CLR status utility" is disappointing and we had to write our own using variations of the above code.

Sample code to enumerate .NET Framework versions

Aaron Stebner's WebLog — Sat, 30 Jul 2005 19:44:24 GMT

I found an interesting post that lists some sample code to enumerate the installed versions of the .NET...

Determining Framework Version | keyongtech

Determining Framework Version | keyongtech — Thu, 22 Jan 2009 08:46:51 GMT

PingBack from http://www.keyongtech.com/426224-determining-framework-version

Updated sample .NET Framework detection code that does more in-depth checking

Aaron Stebner's WebLog — Fri, 29 May 2009 23:48:03 GMT

I previously posted some sample code to detect the version(s) and service pack levels of the .NET Framework