自TFS .NET 4.5升级以来，针对.NET 4.0提供了无效的Win XP应用程序

Question

我们有一个TFS构建服务器（我认为它在TFS术语中称为构建控制器）。它构建并部署了多个解决方案。其中一个解决方案，一个面向.NET 4完整配置文件和x86的Windows窗体项目，曾经在Windows XP上运行良好，现在无法运行消息：

  

* .exe在Windows XP上不是有效的win32应用程序

我们有一个3个月前的版本，工作正常，因此源代码中没有任何相关内容发生变化。但是，当现在从构建服务器请求新构建时，生成的.exe（有很多.dll支持它）无法在Windows XP 32位上运行。在Windows 7 32位和Windows 7 64位上运行相同的构建版本。

我最好猜测在过去三个月内在构建服务器上安装的东西正在发挥作用。已经安装了很多东西，包括.NET 4.5，Visual Studio 2012等。但是，它不应该改变针对4.0的解决方案。

有什么想法吗？

Answer 1

.net 4.5升级.net 4.0所以，如果你的构建服务器上安装了.net 4.5，并且你的目标是.net 4.0，这与你在XP上安装的.net 4.0不同。你不能在XP上安装.net 4.5。 This Blog详细介绍了这一点。

基本上如果你想支持XP，你就不能使用.net 4.5 / Visual Studio 2012.（或者在你的构建机器上安装它们）

Answer 2

有一个old hot big topic on MSDN forum安装了.NET 4.5的机器上的.NET 4.0与安装了.NET 4.5的.NET 4.0不同。换句话说，无法在机器上/从机器上可靠地开发和测试.NET 4.0应用程序安装了.NET 4.5并且必须安装单独的开发和测试机器/环境

尽管如此，SO中有很多答案坚持相反的观点。可能来自同一位作者，我的任何答案都与我的答案相矛盾，例如，here，here，here

Answer 3

这对OP来说可能为时已晚，但我遇到了这个问题并找到了一个适合我的修复程序。构建我的项目会在输出文件夹中生成一个.exe.config文件。此配置有一个启动部分：

{{1}}

我将4.5更改为4.0，现在我的项目在XP（Service Pack 2）上运行没有问题。我链接的所有包和dll都是为4.0构建的。我没有调查它以确定哪一个是罪魁祸首，但我怀疑它是Microsoft.Practices.Unity，因为配置文件似乎与我正在做的依赖注入有关。使用Visual Studio 2013 Update 4在Win7上构建。

Answer 4

尝试将Platform ToolSet更改为使用Visual Studio 2010.然后重建，希望这可能对您有用

Answer 5

.NET 4.5中包含的编译器利用了隐藏的知识，XP不支持.NET 4.5。这使得他们可以做一些早已过期的.NET程序，他们最终可以更改目标操作系统版本。这是在EXE和DLL头中编码的，自.NET首次发布以来，它一直被设置为Windows版本4.00。

您可以使用SDK工具查看目标版本号，Dumpbin.exe / headers命令会显示它。使用/ SUBSYSTEM选项构建后，Editbin.exe实用程序可以更改它。这将是修补程序以使其在XP上运行的一种方法。

Windows会关注EXE中的这个字段。当它看到 less 的目标版本低于6.00时，它将假定该程序最初编写为在Vista之前的旧版本Windows上运行。然后打开一些appcompat功能。最激烈的一点是它会假设您的程序在启用Aero功能时对窗口上的胖边界一无所知。它将谎言关于窗口大小，返回比实际窗口大小小6个像素的值。当他们试图让窗口排成一行时，这个谎言会让一些程序员感到很困惑。

将目标版本设置为6.00，Windows将关闭这样的谎言。并阻止该程序在XP上运行，它不知道6.00版本的含义。假设安装了SP2，它只会达到5.02。

无需回到旧版本的Visual Studio，您接受的答案是错误的。解决方法是一个非常简单的（您实际上并不想使用Editbin.exe），只是针对.NET 4.0而不是4.5。事实上，.NET 4.0在XP上可用。因此，编译器将目标操作系统版本保持在4.00。如果你确定300％确实已经针对.NET 4.0，那么在构建机器配置中就会出现问题。像使用来自c：\ windows \ microsoft.net或GAC而不是c：\ program files \ reference程序集的程序集引用一样令人讨厌。