如何在运行时检测 .NET 4.5 版当前正在运行您的代码? [英] How do I detect at runtime that .NET version 4.5 is currently running your code?

问题描述

我从 http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27541，它替代"了 .NET 4.0 版本.

I installed .NET 4.5 Developer preview from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27541, which 'replaces' .NET 4.0 version.

但是，检测 .NET 框架版本的旧方法似乎返回 4.0(在我的 PC 上更准确地说是 4.0.30319.17020)，而不是 4.5(当然可能是为了向后兼容，或者?):

However, the old way to detect the .NET framework version seems to return 4.0 (more precisely 4.0.30319.17020 on my PC), instead of 4.5 (sure probably for backward compatibility, or?):

using System;

namespace ConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var version = Environment.Version;
            Console.WriteLine(version.ToString());
            Console.ReadKey();
        }
    }
}

如何检测我的代码是否真的由 .NET 4.5 执行?

How do I detect that my code is really executed by .NET 4.5?

推荐答案

您需要明确区分 CLR(即运行时")和框架库(即框架").您在第一个上或使用第一个执行您的代码，您的代码针对后者进行编译并使用后者.不幸的是，当使用术语.NET version"时，通常指的是运行时和框架的整个包，而不管它们各自的版本 - 正如所说 - 可以不同.

You need to make a clear distinction between the CLR (i.e. the "runtime") and the framework libraries (i.e. the "framework"). You execute your code on or with the first, your code is compiled against and uses the later. Unfortunately when using the the term ".NET version" one is usually referring to the whole package of both runtime and framework, regardless of their individual versions which - as has been said - can differ.

您可以检测安装的框架版本.但是，这并不能告诉您在运行时实际使用的是哪个.

You can detect the installed framework versions. That doesn't, however, tell you which one you are actually using at runtime.

我不确定 4.5，但对于 2.0 与 3.0 或 3.5 Environment.Version 没有帮助，因为它总是返回 2.0，因为所有这些框架版本都使用 CLR 2.0.我假设在 framework 4.5 中，CLR 版本仍然是 4.0，这可以解释 Environment.Version 即使在这种情况下也返回 4.0.x.

I'm not sure about 4.5, but with 2.0 vs. 3.0 or 3.5 Environment.Version was of no help since it always returned 2.0 as all those framework versions were using the CLR 2.0. I presume that with the framework 4.5 the CLR version is still 4.0, which would explain that Environment.Version returns 4.0.x even in that case.

一种可能对您有用的技术是检查核心库(mscorlib、System.Core 等)中的类型、方法或属性，您知道这些库仅从特定的 .NET 框架版本开始就存在.

A technique that may work for you is to check for a type, method or property in the core libraries (mscorlib, System.Core, etc.) that you'd know only existed starting with a particular .NET framework version.

例如，ReflectionContext 类在 .NET 框架 4.5 中似乎是全新的，并且方便地位于 mscorlib 中.所以你可以做这样的事情.

For example, the ReflectionContext class seems to be totally new with the .NET framework 4.5 and conveniently lives in mscorlib. So you could do something like this.

  public static bool IsNet45OrNewer()
  {
      // Class "ReflectionContext" exists from .NET 4.5 onwards.
      return Type.GetType("System.Reflection.ReflectionContext", false) != null;
  }

说了这么多，人们可能会质疑为什么您需要知道您使用的是哪个 .NET 版本.只需尝试访问您需要的功能，如果它们不存在，可能会优雅地回退到其他功能(旧版本中可用).

Having all that said, one could question why you need to know which .NET version you are using. Simply try to access the features you require and possibly gracefully fallback to something else (that was available in older versions) if they are not present.

更新:请注意，术语 .NET 4.5 是指构成基类库 (BCL) 及更多(统称为框架")的多个程序集的整个包以及运行时本身，即 CLR - 如前所述，两者都可以有不同的版本.

Update: Note that the term .NET 4.5 refers to the whole package of several assemblies that make up the base class libraries (BCL) and more (collectively called "framework") plus the runtime itself, i.e. the CLR - both of which can have different versions, as has been said.

我不在 Microsoft 工作，也不了解缺少(单个)函数或 API 来获取.NET 框架版本"背后的真正原因，但我可以做出有根据的猜测.

I don't work for Microsoft and have no insight into the real reasons behind the lack of a (single) function or API to get "the .NET framework version", but I can make an educated guess.

1. 尚不清楚此类函数/API 应提供哪些特别的信息.甚至 BCL 的各个程序集也不共享通用(程序集/文件)版本.例如，在 .NET 3.0 和 3.5 中，mscorlib.dll 的版本为 2.0.x，而只有 WCF 和 WF 的新程序集具有 3.0 版本.我认为即使使用 .NET 3.5，System.ServiceModel.dll 仍然有 3.0.x 版.我想说的是，框架的所有程序集都没有统一的版本.那么像 System.Environment.FrameworkVersion 这样的 API 调用应该返回什么?该版本有什么价值(即使它确实返回了像 4.5 这样的符号"版本，它也没有什么价值，不是吗?).

1. It is not clear what information in particular such a function/API should provide. Even the individual assemblies of the BCL don't share a common (assembly/file) version. For example, with .NET 3.0 and 3.5, the mscorlib.dll had version 2.0.x while only the new assemblies of WCF and WF had 3.0 something. I think even with .NET 3.5 the System.ServiceModel.dll still had version 3.0.x. What I'm trying to say, there is no unified version on all assemblies of the framework. So what should an API call like, say, System.Environment.FrameworkVersionreturn? What value would the version be (even if it did return the "symbolic" version like 4.5, it would be of little value, wouldn't it?).

过于具体 某些新功能可能会出现在 SP 的现有版本中，并且是新版本的一部分.进行功能检查时，您的应用程序可能会在以前 已更新的版本上运行良好，而通过显式版本检查，它可能会不必要地将自身限制为最新版本.我没有来自 .NET 世界的示例，但总的来说(以及在 Windows 本身，例如 WMI)它可以并且确实发生了.

Too specific Some new features might arrive in SPs to existing versions, plus being part of a new version. Doing feature checking, your application might run perfectly well on previous versions, that have been updated, while with explicit version checking it might unneccessarily restrict itself to the newest version. I don't have an example from the .NET world for this, but in general (and in Windows itself, e.g. WMI) it can and did happen.

不需要.我可以想象，一种计算应用程序当前正在使用的框架版本"的方法甚至可取为他们提供.版本检查谬误(有关适用于 .NET 的概念，请参阅不要检查版本"段落)，在本机/Win32 世界中.例如，人们错误地使用了 GetVersion 和 GetVersionEx API，他们只检查他们运行的版本是否是他们在编写应用程序时知道的最新版本.因此，当应用程序在较新版本的 Windows 上运行时，它不会运行，即使他们真正使用的功能仍然存在.微软可能已经考虑过类似的问题，因此甚至没有在 .NET 中提供一些 API.

Not wanted. I could imagine that a method to figure "the version of the framework" that is currently being used by an application is not even desirable for them to provide. There is a long and unholy history of version checking fallacies (see "Don't Check Version" paragraph for concepts that apply to .NET as well), in the native/Win32 world. For example, people used the GetVersion and GetVersionEx APIs wrong, by only checking that they run the version they knew was the newest when they wrote their application. So, when the application was run on a newer version of windows, it wouldn't run, even though the features they really were using are still there. Microsoft might have considered issues like that and thus not even provided some API in .NET.

顺便说一下，这就是 Microsoft recommends 在 GetVersion 函数的备注部分:

Incidentally this is what Microsoft recommends in the remarks section of the GetVersion function:

识别当前的操作系统通常不是最好的方法以确定是否存在特定的操作系统功能.这是因为操作系统可能添加了新功能在可再发行的 DLL 中.而不是使用 GetVersionEx 来确定操作系统平台或版本号，测试是否存在功能本身.

Identifying the current operating system is usually not the best way to determine whether a particular operating system feature is present. This is because the operating system may have had new features added in a redistributable DLL. Rather than using GetVersionEx to determine the operating system platform or version number, test for the presence of the feature itself.

Windows 团队博客也有一些内容 说这个.

The Windows Team Blog also has something to say about this.

我知道这一切都与 Windows 和本机编程有关，但对于 .NET 应用程序、框架和 CLR 而言，概念和危险是相同的.

I know all this was about Windows and native programming, but the concept and dangers are the same for .NET applications the framework and the CLR.

因此，我认为使用(优雅)回退进行功能检查是确保您的应用程序向下兼容的更可靠和稳健的方法.如果您只想让您的应用程序使用特定版本的 .NET 或更新版本，请不要做任何特别的事情，并依靠 .NET 本身的向后兼容性.

I would say feature checking with (graceful) fallback is thus a much more reliable and robust way to make sure your application is downwards compatible. If you only want your application to work with a specific version of .NET or newer, don't do anything special at all and count on the backwards compatibility of .NET itself.

这篇关于如何在运行时检测 .NET 4.5 版当前正在运行您的代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！