J'hésite à poster cette réponse, c'est en fait techniquement possible mais ça ne marche pas très bien en pratique. Les numéros de version du CLR et des assemblys de structure de base n'ont pas été modifiés dans la version 4.5. Vous ciblez toujours la v4.0.30319 du CLR et les numéros de version de l'assembly du framework sont toujours 4.0.0.0. La seule chose qui distingue le manifeste d'assembly lorsque vous le regardez avec un désassembleur comme ildasm.exe est la présence d'un attribut [TargetFramework] qui indique que 4.5 est nécessaire, qui devrait être modifié. Pas vraiment simple, il est émis par le compilateur.
La plus grande différence n'est pas si visible, Microsoft a apporté une modification attendue depuis longtemps dans l'en-tête exécutable des assemblys. Qui spécifie la version de Windows avec laquelle l'exécutable est compatible. XP appartient à une génération précédente de Windows, démarrée avec Windows 2000. Leur numéro de version majeur est 5. Vista était le début de la génération actuelle, numéro de version majeure 6.
Les compilateurs .NET ont toujours spécifié le numéro de version minimum à 4,00, la version de Windows NT et Windows 9x. Vous pouvez le voir en exécutant dumpbin.exe / headers sur l'assembly. L'exemple de sortie ressemble à ceci:
OPTIONAL HEADER VALUES
10B magic # (PE32)
...
4.00 operating system version
0.00 image version
4.00 subsystem version
0 Win32 version
...
Ce qui est nouveau dans .NET 4.5, c'est que les compilateurs modifient cette version de sous-système en 6.00. Un changement qui était en grande partie dû au fait que Windows accorde une attention particulière à ce nombre, au-delà de la simple vérification s'il est suffisamment petit. Il active également les fonctionnalités appcompat car il suppose que le programme a été écrit pour fonctionner sur les anciennes versions de Windows. Ces fonctionnalités causent des problèmes, en particulier la façon dont Windows ment sur la taille d'une fenêtre dans Aero est gênante. Il cesse de mentir sur les grosses bordures d'une fenêtre Aero quand il peut voir que le programme a été conçu pour fonctionner sur une version de Windows qui a Aero.
Vous pouvez modifier ce numéro de version et le redéfinir sur 4,00 en exécutant Editbin.exe sur vos assemblys avec l'option / subsystem. Cette réponse montre un exemple d'événement postbuild.
C'est cependant là que se terminent les bonnes nouvelles, un problème important est que .NET 4.5 n'est pas très compatible avec .NET 4.0. De loin, le plus gros problème est que les classes ont été déplacées d'un assemblage à un autre. Plus particulièrement, cela s'est produit pour l'attribut [Extension]. Auparavant dans System.Core.dll, il a été déplacé vers Mscorlib.dll dans .NET 4.5. C'est un kaboom sur XP si vous déclarez vos propres méthodes d'extension, votre programme dit de chercher dans Mscorlib l'attribut, activé par un attribut [TypeForwardedTo] dans la version .NET 4.5 de l'assembly de référence System.Core. Mais ce n'est pas là lorsque vous exécutez votre programme sur .NET 4.0
Et bien sûr, rien ne vous aide à arrêter d'utiliser des classes et des méthodes qui ne sont disponibles que sur .NET 4.5. Lorsque vous le faites, votre programme échouera avec une exception TypeLoadException ou MissingMethodException lorsqu'il est exécuté sur 4.0
Ciblez simplement 4.0 et tous ces problèmes disparaissent. Ou brisez ce blocage et arrêtez de prendre en charge XP, une décision commerciale que les programmeurs ne peuvent pas souvent prendre mais peuvent certainement encourager en soulignant les tracas que cela cause. Il y a bien sûr un coût non nul à devoir prendre en charge les anciens systèmes d'exploitation, seul l'effort de test est substantiel. Un coût qui n'est pas souvent reconnu par la direction, la compatibilité Windows est légendaire, à moins que cela ne leur soit signalé. Transmettez ce coût au client et il a tendance à prendre la bonne décision beaucoup plus rapidement :) Mais nous ne pouvons pas vous aider.