Determining an Image’s CLR Version

  • Article

To get it programmatically, from managed code, use Assembly.ImageRuntimeVersion. From unmanaged, use mscoree.dll's GetFileVersion(). (From the command line, starting in v2.0, ildasm.exe will show it if you double-click on "MANIFEST" and look for "Metadata version".) Those will give you the CLR version that the image claims it wants. By default, it's the version that the image was compiled against. That's not necessarily what it will be, however, since compilers can be configured to put any string there.

Also, the CLR version that will be run by an exe is not necessarily the same as what is in its image runtime version. The chosen version can also depend on its hosting application's choice, a config file, environment variables, and registry settings. If you need to override those, you can set the supportedRuntime/requiredRuntime in the app.config for the process exe.

Comments

  • Anonymous
    June 23, 2003
    Suzanne thank you very much for blogging. Your blog is easily one of the more usefull blogs I've seen.Could you please describe what happens when shadoing is enabled (what part of the file/bits compared to determine if clr can abort download and use cached version)Thank you again.

  • Anonymous
    June 23, 2003
    Iif the assembly is strongly-named, and an assembly by that exact identity (simple name, version, culture, public key token) has already been downloaded, Fusion won't re-download it. The CLR also does some caching of its own: if we've seen this exact reference before in that appdomain, we don't ask Fusion for it.

  • Anonymous
    June 24, 2003
    That seem to apply only to Load(). What about LoadFrom() ?What about NOT strongly-named assemblies.I observed that gacutil /ldl seems not to show any new downloaded files when I start app multiple times.Please explain as much as you can.

  • Anonymous
    June 24, 2003
    Do you mean .Net Framework 1.2? I thought the next version would be 2.0, the one coming with Yukon... Did I miss something?

  • Anonymous
    June 27, 2003
    David: Today, the version is 1.2, but it may change by the time it ships. Dmitriy: It's not context dependent. Non-strongly-named assemblies will be re-downloaded.

  • Anonymous
    July 21, 2003
    David: Looks like it will be 2.0 instead of 1.2, now, so I updated my entry. :)

  • Anonymous
    August 30, 2005
    If V1.1 application that has COM interop is running on a machine with both V1.1 and V2 .NET runtime installed, which version of the runtime the application will be running against V1.1 or V2. Will this change if the app has a configuration file target to V1.1?

  • Anonymous
    January 10, 2007
    When I try to use the GetFileVersion in a unmanaged C++ program, I get link errors complaining about missing symbol for GetFileVersion. I am linking to mscoree.lib. Is there any other library that I need to link against?

  • Anonymous
    February 21, 2007
    Thanks for the ildasm tip. I've been looking all over and finally got google to point me here.

  • Anonymous
    April 12, 2007
    I typically recommend that you build and test your assemblies against the same version of .NET that you

  • Anonymous
    February 26, 2008
    Whats the difference between "Metadata version" and CLR Header major minor version? They both seem to refer to the same thing which doesn't make sense. Using corflags (vs2005 utility) show both these attributes, the CLR Header version can also be found using dumpbin and "metadata version" can be found using ildasm. Thanks for any help :)