我毫不犹豫地张贴这个答案，它实际上是技术上是可行的，但它不工作了很好的实践。 CLR和核心框架组件的版本号在4.5均未改变。您还针对CLR的v4.0.30319和框架集的版本号仍然是4.0.0.0。唯一的事情，就是与众不同的有关程序集清单中，当你看它与像程序Ildasm.exe反汇编器是一个[TargetFramework]属性，指出4.5是必要的，这将有被改变的presence。实际上并没有那么简单，它是由编译器发出的。

I hesitate to post this answer, it is actually technically possible but it doesn't work that well in practice. The version numbers of the CLR and the core framework assemblies were not changed in 4.5. You still target v4.0.30319 of the CLR and the framework assembly version numbers are still 4.0.0.0. The only thing that's distinctive about the assembly manifest when you look at it with a disassembler like ildasm.exe is the presence of a [TargetFramework] attribute that says that 4.5 is needed, that would have to be altered. Not actually that easy, it is emitted by the compiler.

最大的不同就是没有那么明显，微软在组件的可执行文件头部做了一个期待已久的变化。它指定的Windows版本的可执行文件兼容。 XP属于previous一代的Windows，开始与Windows 2000在主要的版本号是5，Vista的是这一代开始，主版本号6。

The biggest difference is not that visible, Microsoft made a long-overdue change in the executable header of the assemblies. Which specifies what version of Windows the executable is compatible with. XP belongs to a previous generation of Windows, started with Windows 2000. Their major version number is 5. Vista was the start of the current generation, major version number 6.

.NET编译器始终指定的最低版本号为4.00，对Windows NT和Windows 9x的版本。您可以通过在装配运行DUMPBIN.EXE /头看到这一点。示例输出如下：

.NET compilers have always specified the minimum version number to be 4.00, the version of Windows NT and Windows 9x. You can see this by running dumpbin.exe /headers on the assembly. Sample output looks like this:

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。这些特点造成麻烦，尤其是Windows谎言大约一个窗口，在航空大小的方法是麻烦。它停止撒谎的航空窗口的脂肪边界的时候才可以看到，该方案的目的是要在一个Windows版本有航空运行。

What's new in .NET 4.5 is that the compilers change that subsystem version to 6.00. A change that was over-due in large part because Windows pays attention to that number, beyond just checking if it is small enough. It also turns on appcompat features since it assumes that the program was written to work on old versions of Windows. These features cause trouble, particularly the way Windows lies about the size of a window in Aero is troublesome. It stops lying about the fat borders of an Aero window when it can see that the program was designed to run on a Windows version that has Aero.

您可以改变的版本号，并将其设置回4.00您的组件与/子系统选项运行Editbin.exe。 这个答案显示了一个示例postbuild事件。

You can alter that version number and set it back to 4.00 by running Editbin.exe on your assemblies with the /subsystem option. This answer shows a sample postbuild event.

这可是哪里好消息结束，一个显著的问题是，.NET 4.5是不是与.NET 4.0中非常兼容。到目前为止最大的挂断是类被移动从一个组件到另一个。最值得注意的是，发生在[扩展]属性。 previously在System.Core.dll的，它被认为是转移到MSCORLIB.DLL在.NET 4.5。这是在XP上一个KABOOM如果你声明自己的扩展方法，你的程序说，看在Mscorlib中的属性，由[TypeForwardedTo]属性在.NET 4.5版本System.Core程序引用程序集的启用。但它不存在，当你在.NET 4.0中运行您的程序

That's however about where the good news ends, a significant problem is that .NET 4.5 isn't very compatible with .NET 4.0. By far the biggest hang-up is that classes were moved from one assembly to another. Most notably, that happened for the [Extension] attribute. Previously in System.Core.dll, it got moved to Mscorlib.dll in .NET 4.5. That's a kaboom on XP if you declare your own extension methods, your program says to look in Mscorlib for the attribute, enabled by a [TypeForwardedTo] attribute in the .NET 4.5 version of the System.Core reference assembly. But it isn't there when you run your program on .NET 4.0

当然，没有什么可以帮助您停止使用类和方法仅适用于.NET 4.0。当你这样做，在4.0上运行，当你的程序将无法与TypeLoadException或的MissingMethodException

And of course there's nothing that helps you stop using classes and methods that are only available on .NET 4.0. When you do, your program will fail with a TypeLoadException or MissingMethodException when run on 4.0

只是针对4.0和所有这些问题消失。或者打破这种僵局，并停止支持XP，一个商业决定，程序员不能经常做，但肯定可以鼓励指出，这是造成麻烦。当然有一个非零成本具有支持古操作系统，只是测试工作是相当大的。一个不经常被管理层认可的成本，Windows兼容性是传说中的，除非是向他们指出。转发成本给客户，他们往往会做出正确的决定快得多:)但是，我们不能帮你了。

Just target 4.0 and all of these problems disappear. Or break that logjam and stop supporting XP, a business decision that programmers cannot often make but can certainly encourage by pointing out the hassles that it is causing. There is of course a non-zero cost to having to support ancient operating systems, just the testing effort is substantial. A cost that isn't often recognized by management, Windows compatibility is legendary, unless it is pointed out to them. Forward that cost to the client and they tend to make the right decision a lot quicker :) But we can't help you with that.