Dudo en publicar esta respuesta, en realidad es técnicamente posible pero no funciona tan bien en la práctica. Los números de versión de CLR y los ensamblados del marco principal no se cambiaron en 4.5. Aún tiene como destino v4.0.30319 de CLR y los números de versión del ensamblado del marco siguen siendo 4.0.0.0. Lo único que distingue al manifiesto de ensamblado cuando lo mira con un desensamblador como ildasm.exe es la presencia de un atributo [TargetFramework] que dice que se necesita 4.5, que tendría que modificarse. En realidad, no es tan fácil, lo emite el compilador.
La mayor diferencia no es tan visible, Microsoft hizo un cambio muy esperado en el encabezado ejecutable de los ensamblados. Que especifica con qué versión de Windows es compatible el ejecutable. XP pertenece a una generación anterior de Windows, que comenzó con Windows 2000. Su número de versión principal es 5. Vista fue el comienzo de la generación actual, la versión principal número 6.
Los compiladores de .NET siempre han especificado que el número de versión mínimo sea 4.00, la versión de Windows NT y Windows 9x. Puede ver esto ejecutando dumpbin.exe / headers en el ensamblado. La salida de muestra se ve así:
OPTIONAL HEADER VALUES
10B magic # (PE32)
...
4.00 operating system version
0.00 image version
4.00 subsystem version
0 Win32 version
...
Lo nuevo en .NET 4.5 es que los compiladores cambian esa versión del subsistema a 6.00. Un cambio que se retrasó en gran parte porque Windows presta atención a ese número, más allá de solo verificar si es lo suficientemente pequeño. También activa las funciones de appcompat, ya que asume que el programa fue escrito para funcionar en versiones antiguas de Windows. Estas características causan problemas, particularmente la forma en que Windows miente sobre el tamaño de una ventana en Aero es problemático. Deja de mentir sobre los bordes gruesos de una ventana de Aero cuando puede ver que el programa fue diseñado para ejecutarse en una versión de Windows que tiene Aero.
Puede modificar ese número de versión y volver a establecerlo en 4.00 ejecutando Editbin.exe en sus ensamblados con la opción / subsystem. Esta respuesta muestra un evento posterior a la compilación de muestra.
Sin embargo, ahí es donde terminan las buenas noticias, un problema importante es que .NET 4.5 no es muy compatible con .NET 4.0. Con mucho, el mayor problema es que las clases se trasladaron de una asamblea a otra. En particular, eso sucedió con el atributo [Extensión]. Anteriormente en System.Core.dll, se movió a Mscorlib.dll en .NET 4.5. Eso es un kaboom en XP si declara sus propios métodos de extensión, su programa dice que busque en Mscorlib el atributo, habilitado por un atributo [TypeForderedTo] en la versión .NET 4.5 del ensamblado de referencia System.Core. Pero no está ahí cuando ejecuta su programa en .NET 4.0
Y, por supuesto, no hay nada que le ayude a dejar de usar clases y métodos que solo están disponibles en .NET 4.5. Cuando lo haga, su programa fallará con una TypeLoadException o MissingMethodException cuando se ejecute en 4.0
Solo apunte a 4.0 y todos estos problemas desaparecerán. O rompa ese atasco y deje de admitir XP, una decisión comercial que los programadores no pueden tomar con frecuencia, pero que ciertamente pueden alentar al señalar los problemas que está causando. Por supuesto, el tener que soportar sistemas operativos antiguos tiene un costo distinto de cero, solo que el esfuerzo de prueba es sustancial. Un costo que a menudo no es reconocido por la administración, la compatibilidad con Windows es legendaria, a menos que se les indique. Transmita ese costo al cliente y ellos tienden a tomar la decisión correcta mucho más rápido :) Pero no podemos ayudarlo con eso.