如何检查可执行文件是否与已安装的 .NET 版本兼容
How check if an executable is compatible to the installed .NET version
我是一名软件测试员。我得到了一个可执行文件来在给定的机器上进行测试。在测试中，可执行文件表现得很奇怪，任何人都无法解释。
经过大量研究和调试，我找到了原因：为 .NET 目标框架 4.6 构建的可执行文件，但机器配备了 .NET 4.5。
这甚至为像 "string.Format()" 这样的微不足道的方法产生了一些 "MissingMethodExeception"。一些 try-catch 捕获了这些异常，但以错误的方式处理它们，因为没有人预料到它们会发生。
这里描述了一个类似的问题：
我的问题：
- 当我尝试 运行 由于必要的 .NET 版本不可用而无法正确 运行 的可执行文件时，Windows 不是要警告我吗？
- 通常处理此问题的最佳做法是什么？
（我希望在 VisualStudio 中出现类似复选框 "Dont execute if target network is not available" 的东西？！）
回答问题：
- 否 Windows 并不是要警告您所需的 .Net Framework 未安装到 运行 此可执行文件。但是，Windows 将在 Windows 事件日志中记录错误或应用程序崩溃信息。
关于第二个问题...
- 通常，可执行文件是使用安装程序交付、部署或发布的。安装程序可以是 configured/written，如果未安装 .Net 框架（exe/dll 需要），它们会警告用户。
Isn't Windows meant to warn me ...
您肯定会收到警告，不是来自 Windows，而是来自 CLR。嵌入在程序集中的对话框 looks like this, clicking Yes automatically gets the required framework version deployed and installed on the machine. The CLR performs this check by looking for the [TargetFramework] attribute。如前所述，运行 ildasm.exe 来验证此属性。期望它丢失或具有足够低的值，因此不会触发对话框。
What is the best practice to deal with this problem in general?
这是程序错误，程序集构建错误。您确信编译器使用了仅适用于 .NET 4.6 版的参考程序集。这必须追溯到构建它的机器，很可能是构建服务器。它没有正确设置，当构建工程师通过避免使用 Visual Studio 的许可副本来偷工减料时，这种事故很常见。或者通过偏爱免费软件工具，Jenkins 是一个常见的祸害。
除了 [TargetFramework] 属性错误或丢失之外，这种特殊的事故特别容易诱发。它所需要的只是使用 c:\windows\microsoft.net\framework 中的程序集作为参考程序集，而不是需要目标包并安装在 c:\program files (x86)\reference assemblies 中的正确程序集目录。 This Q+A 有更多潜在客户。
修复构建服务器往往有很多阻力点，作为测试人员最好的办法是提交错误报告。您还想为损坏的 catch-em-all 异常处理编写一个，这使得问题很难诊断。
我是一名软件测试员。我得到了一个可执行文件来在给定的机器上进行测试。在测试中，可执行文件表现得很奇怪，任何人都无法解释。
经过大量研究和调试，我找到了原因：为 .NET 目标框架 4.6 构建的可执行文件，但机器配备了 .NET 4.5。 这甚至为像 "string.Format()" 这样的微不足道的方法产生了一些 "MissingMethodExeception"。一些 try-catch 捕获了这些异常，但以错误的方式处理它们，因为没有人预料到它们会发生。
这里描述了一个类似的问题：
我的问题：
- 当我尝试 运行 由于必要的 .NET 版本不可用而无法正确 运行 的可执行文件时，Windows 不是要警告我吗？
- 通常处理此问题的最佳做法是什么？
（我希望在 VisualStudio 中出现类似复选框 "Dont execute if target network is not available" 的东西？！）
回答问题：
- 否 Windows 并不是要警告您所需的 .Net Framework 未安装到 运行 此可执行文件。但是，Windows 将在 Windows 事件日志中记录错误或应用程序崩溃信息。
关于第二个问题...
- 通常，可执行文件是使用安装程序交付、部署或发布的。安装程序可以是 configured/written，如果未安装 .Net 框架（exe/dll 需要），它们会警告用户。
Isn't Windows meant to warn me ...
您肯定会收到警告，不是来自 Windows，而是来自 CLR。嵌入在程序集中的对话框 looks like this, clicking Yes automatically gets the required framework version deployed and installed on the machine. The CLR performs this check by looking for the [TargetFramework] attribute。如前所述，运行 ildasm.exe 来验证此属性。期望它丢失或具有足够低的值，因此不会触发对话框。
What is the best practice to deal with this problem in general?
这是程序错误，程序集构建错误。您确信编译器使用了仅适用于 .NET 4.6 版的参考程序集。这必须追溯到构建它的机器，很可能是构建服务器。它没有正确设置，当构建工程师通过避免使用 Visual Studio 的许可副本来偷工减料时，这种事故很常见。或者通过偏爱免费软件工具，Jenkins 是一个常见的祸害。
除了 [TargetFramework] 属性错误或丢失之外，这种特殊的事故特别容易诱发。它所需要的只是使用 c:\windows\microsoft.net\framework 中的程序集作为参考程序集，而不是需要目标包并安装在 c:\program files (x86)\reference assemblies 中的正确程序集目录。 This Q+A 有更多潜在客户。
修复构建服务器往往有很多阻力点，作为测试人员最好的办法是提交错误报告。您还想为损坏的 catch-em-all 异常处理编写一个，这使得问题很难诊断。