C# 是否可以在XP上运行.NET 4.5应用程序？

首先，我读了以下内容：

尤其是 因此，从最后一个项目来看，我真的认为没有办法解决这个问题，但我必须看看我是否能得到一个明确的答案，因为我的团队希望从.NET 4.0升级到.NET 4.5。然而，我们必须支持XP

如果我们想支持XP，是否不可能使用.NET4.5

我唯一能想到的是创建两个独立的解决方案，但是如果我们使用.NET4.5特性，那么代码库将不得不出现分歧

所以，我正在寻找一些我找不到的、其他人可能已经知道的令人惊奇的解决方法

以及连接页面中的相关帖子：

微软于2012年3月23日10:39发布 谢谢你的报告。此行为是在.NET Framework 4.5测试版中设计的。支持的最低操作系统是Windows 7、Windows Server 2008 SP2和Windows Server 2008 R2 SP1。Windows XP不是Beta版支持的操作系统

---

我不太愿意发布这个答案，它实际上在技术上是可行的，但在实践中效果并不好。CLR和核心框架程序集的版本号在4.5中没有更改。您仍然以CLR的v4.0.30319为目标，框架程序集版本号仍然是4.0.0.0。当您使用像ildasm.exe这样的反汇编程序查看程序集清单时，它唯一与众不同的地方是存在一个[TargetFramework]属性，该属性表示需要4.5，必须对其进行更改。实际上没有那么容易，它是由编译器发出的

最大的区别并不是显而易见的，微软在程序集的可执行文件头中做了一个早就应该做的更改。它指定可执行文件与哪个版本的Windows兼容。XP属于上一代Windows，从Windows 2000开始。它们的主要版本号是5。Vista是当前一代的开始，主要版本号为6

.NET编译器始终将最低版本号指定为4.00，即Windows NT和Windows 9x的版本。通过在程序集上运行dumpbin.exe/headers可以看到这一点。示例输出如下所示：

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            ...
            4.00 operating system version
            0.00 image version
            4.00 subsystem version              // <=== here!!
               0 Win32 version
            ...

NET 4.5中的新功能是编译器将该子系统版本更改为6.00。这一变化的结束在很大程度上是因为Windows关注这个数字，而不仅仅是检查它是否足够小。它还启用appcompat功能，因为它假定程序是为在旧版本的Windows上工作而编写的。这些特性会带来麻烦，尤其是在Aero中窗口大小与窗口大小有关的方式非常麻烦。当它可以看到该程序被设计为在安装了Aero的Windows版本上运行时，它就不再在Aero窗口的肥边上撒谎了

通过使用/subsystem选项在程序集上运行Editbin.exe，可以更改该版本号并将其设置回4.00。显示了一个生成后事件示例

然而，好消息到此为止，一个重要的问题是.NET4.5与.NET4.0不太兼容。到目前为止，最大的障碍是类从一个程序集移动到另一个程序集。最值得注意的是，[Extension]属性就是这样。以前在System.Core.dll中，它被移动到.NET 4.5中的Mscorlib.dll。如果声明自己的扩展方法，程序会在Mscorlib中查找属性，该属性由System.Core引用程序集的.NET 4.5版本中的[TypeForwardedTo]属性启用。但是当你在.NET4.0上运行你的程序时，它就不存在了

当然，没有什么可以帮助您停止使用仅在.NET4.5上可用的类和方法。当您这样做时，在4.0上运行时，您的程序将因TypeLoadException或MissingMethodException而失败

只要瞄准4.0，所有这些问题就会消失。或者打破僵局，停止支持XP，这是程序员通常无法做出的商业决策，但肯定可以通过指出它所带来的麻烦来鼓励。当然，支持古老的操作系统需要付出非零的代价，只是测试工作量很大。管理层通常不会意识到这一成本，除非向他们指出，否则Windows兼容性是传奇性的。将成本转嫁给客户，他们往往会更快地做出正确的决定：但我们无法帮助您。

试试mono:

---

此下载适用于所有版本的Windows XP、2003、Vista和Windows 7。

Mono项目放弃了对Windows XP的支持，忘了提及它。尽管他们仍然声称WindowsXPSP2是受支持的最低版本，但实际上它是WindowsVista

---

支持Windows XP的最后一个Mono版本是3.2.3。

支持Windows XP SP3的最后一个版本是Mono-4.3.2.467-gtksharp-2.12.30.1-win32-0.msi，它并没有取代.NET 4.5，但可能对某些应用程序感兴趣

见t 在这里：

---

不，你不能。坚持使用4.0，直到XP死掉。谢谢Hans，我发现有一些突破性的变化。我也很欣赏这种变通方法。由于您指定的原因，我们不能同意，但很高兴知道。也许XP有一天会永远消失……只是测试工作是巨大的——这就是为什么我们的管理层允许放弃XP支持。我知道这是一个老帖子——但是@JustinPihony：您的公司有没有想过安装一个更高版本的操作系统，然后安装VMWare或Virtual Box？对于Windows7来说已经有点晚了，但是微软提供了一个虚拟的WindowsXP安装，允许你在7和XP之间切换。只是一个想法-@马克曼宁，这不在我们的控制范围之内。它被用在其他地方。@JustinPihony:啊。嗯。。。。。。我唯一的另一个建议是一个kluge。捕获操作系统版本，然后将类中的所有函数设置为数组或数组。让一个阵列或阵列的一部分用于XP，另一个用于较新的OSs。然后，您只需要某种全局变量，用于表示要使用的集合。这些呼叫可以是相同的，也可以是相同的，但其中一组使用NET40，其他的可以使用NET45。这将是对函数本身的间接调用。这有意义吗？Mono比.NET慢，虽然它具有.NET4.5的大部分功能，但它缺少WPF等某些主要组件。所以，如果Mono提供了您所需要的一切，并且您对性能影响还可以接受的话，您可以使用Mono for XP支持。从好的方面来说，应该不需要创建特殊的Mono版本，正常的.NET 4.5版本通常在Mono下工作，但您需要专门针对Mono进行测试以确保兼容。我在Windows XP SP3下尝试了Mono-3.12.1-gtksharp-2.12.26-win32-0.msi，但由于Mono.exe不是有效的win32应用程序而失败。我还尝试了mono-3.0.10-gtksharp-2.12.11-win32-0.exe，但在mono.exe下失败-找不到入口点。在动态链接库KERNEL32.dll中找不到过程入口点InterlockedCompareeExchange64。