I hesitate to publish this answer, it is actually technically possible, but in practice it is not so good. The version numbers of the CLR and prefabricated kernel modules were not changed in 4.5. You are still targeting v4.0.30319 from the CLR, and assembly version numbers of the assembly are still 4.0.0.0. The only thing that is typical of an assembly manifest when you look at it with a disassembler such as ildasm.exe is the presence of the [TargetFramework] attribute, which says 4.5 is required, which needs to be changed. This is actually not so simple, it is emitted by the compiler.
The biggest difference is not so noticeable, Microsoft made a lasting change in the executable header of the assemblies. Determines which version of Windows the executable is compatible with. XP refers to the previous generation of Windows running with Windows 2000. Their major version number is 5. Vista was the beginning of the current generation, major version 6.
.NET compilers have always indicated a minimum version number of 4.00, a version of Windows NT, and Windows 9x. You can see this by running dumpbin.exe / headers on the assembly. An example output is as follows:
OPTIONAL HEADER VALUES 10B magic
What's new in .NET 4.5 is that compilers will change the subsystem version to 6.00. Changes that were excessive, mainly because Windows pays attention to this number, with the exception of checking if it is enough. It also includes appcompat functions, as it assumes that the program was written to work on older versions of Windows. These features cause problems, especially how Windows lays around the window size in Aero. It stops lying around the bold borders of the Aero window when it sees that the program was designed to run on a version of Windows with Aero.
You can change this version number and set it back to 4.00 by running Editbin.exe on your builds with the option / subsystem. This answer shows an example postbuild.
As for where the good news ends, the significant problem is that .NET 4.5 is not very compatible with .NET 4.0. By far the biggest hang is that classes moved from one assembly to another. In particular, this happened for the [Extension] attribute. Previously in System.Core.dll, it was ported to Mscorlib.dll in .NET 4.5. This is kaboom on XP, if you declare your own extension methods, your program says to look in Mscorlib for the attribute activated by the [TypeForwardedTo] attribute in the .NET 4.5 version of the System.Core reference assembly. But it is not when you run your program on .NET 4.0
And, of course, there is nothing to stop using the classes and methods available only on .NET 4.5. When you do this, your program will exit with a TypeLoadException or MissingMethodException error when starting 4.0
Just set goal 4.0 and all these problems will disappear. Or break this trap and stop supporting XP, a business decision that programmers cannot make often, but can certainly encourage by pointing out the cramps that it causes. Of course, there is no unnecessary cost to support older operating systems, just the testing effort is substantial. The cost, which is often recognized by management, Windows compatibility is legendary, unless it is indicated on them. Forward, what is the client, and they tend to make the right decision much faster :) But we can not help you.