如何识别程序集被加载到哪个框架中？
一位用户向我们报告，我们的应用程序中的一些奇怪行为可以在安装 .NET 4 后得到解决：
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
我不知道如果您没有指定程序集，它可能会以更高但兼容的版本加载。
是否可以识别可执行文件正在使用哪个框架执行？在运行时？或者通过一些外部过程？我想确认情况确实如此，并且用户体验并不是其他问题造成的。
Process Explorer 说 EVEMon 在 2.0 下运行，我倾向于怀疑问题是环境问题：
A user reported to us that some strange behaviour in our application can be resolved after installing .NET 4:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
I wasn't aware that if you didn't specify an assembly it might be loaded in a higher, but compatible version.
Is it possible to identify which framework an executable is executing with? at run-time? or through some external process? I wish to confirm that this is the case, and the users experience has not be the result of some other issue.
Process Explorer says EVEMon is running under the 2.0, I am inclined to suspect the issue is was environmental:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在程序集的运行代码中，您可以使用 System.Environment.Version 静态属性来确定它正在执行的 CLR 版本。
如果您不想更改汇编代码，可以使用 Process Explorer 查看运行时进程中加载的 DLL。 CLR版本可以通过mscoree.dll的版本来识别。
From within your assembly's running code, you can use the System.Environment.Version static property to determine the CLR version under which it is executing.
If you don't want to change the assembly code, you could use Process Explorer to see the DLLs loaded in the process at runtime. The CLR version can be identified from the version of mscoree.dll.
没有意义，针对 CLR 版本 2.0.50727 的程序不会自动与 .NET 4.0 一起运行。需要显式 .config 文件条目。考虑到您的客户在 .config 文件方面的能力，这可能是她实际上所做的事情，然后发现有麻烦。
Doesn't make sense, a program that was targeted for CLR version 2.0.50727 won't automatically run with .NET 4.0. An explicit .config file entry is required. Given your client's prowess with .config files, this might be something that she in fact did, then found out there was trouble.
正如 Nicole 所说，Process Explorer 绝对是最简单的方法。您还可以使用 WindDBG 从完整内存转储中获取此信息。
另请注意，在 4.0 中，您可以并排 CLR 托管。在 4.0 之前，如果您不拥有该进程，则您拥有 无法知道加载了什么 CLR。这可能是您出现所描述的行为的原因。
As Nicole said Process Explorer is definitely the easiest way. You can also get this information from a Full Memory Dump using WindDBG.
Also note that with 4.0 you get side by side CLR hosting. Prior to 4.0 if you didn't own the process you had no way of knowing what CLR was loaded. This can be a reason why you experinced the behavior you described.