Determining an Image’s CLR Version

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 (11)

  1. Dmitriy Zaslavskiy says:

    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.

  2. Suzanne says:

    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.

  3. Dmitriy Zaslavskiy says:

    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.

  4. David says:

    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?

  5. Suzanne says:

    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.

  6. Suzanne says:

    David: Looks like it will be 2.0 instead of 1.2, now, so I updated my entry. 🙂

  7. Harry says:

    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?

  8. Amit says:

    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?

  9. WanFactory says:

    Thanks for the ildasm tip. I’ve been looking all over and finally got google to point me here.

  10. I typically recommend that you build and test your assemblies against the same version of .NET that you

  11. Lars says:

    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 🙂

Skip to main content