J'ai hésité à poster cette réponse, effectivement, il est techniquement possible, mais il ne fonctionne pas dans la pratique. Les numéros de version du CLR et le cadre de base des assemblages n'ont pas été modifiés dans la version 4.5. Vous avez encore la cible v4.0.30319 de la CLR et le cadre de l'assemblée numéros de version sont encore 4.0.0.0. La seule chose qui distingue le manifeste d'assembly quand vous le regardez avec un désassembleur comme ildasm.exe est la présence d'un [TargetFramework] attribut qui dit que 4,5 est nécessaire, qui devra être modifié. En réalité pas si facile, il est émis par le compilateur.
La plus grande différence n'est pas visible, Microsoft fait une longue souffrance changement dans le fichier exécutable de l'en-tête de l'assemblée. Qui indique quelle version de Windows le fichier exécutable qui est compatible avec. XP appartient à une génération précédente de Windows, a commencé avec Windows 2000. Leur numéro de version majeur est de 5. Vista a été le début de la génération actuelle, de grands numéro de version 6.
.NET compilateurs ont toujours spécifié le numéro de version minimale à 4.00, la version de Windows NT et Windows 9x. Vous pouvez voir cela en cours d'exécution dumpbin.exe /en-têtes, sur l'assemblée. Exemple de sortie ressemble à ceci:
OPTIONAL HEADER VALUES
10B magic # (PE32)
...
4.00 operating system version
0.00 image version
4.00 subsystem version // <=== here!!
0 Win32 version
...
Ce qui est nouveau .NET 4.5, c'est que les compilateurs du changement qui sous-système de version 6.00. Un changement qui n'était dû en grande partie à cause de Windows prête attention à ce nombre, au-delà de juste vérifier si il est assez petit. Il s'allume aussi appcompat fonctionnalités puisqu'elle suppose que le programme a été écrit pour fonctionner sur les anciennes versions de Windows. Ces caractéristiques causer des problèmes, en particulier la façon dont Windows se trouve à environ la taille d'une fenêtre en Aero, est gênante. Il s'arrête de mentir au sujet de la graisse frontières d'un Aéro fenêtre, quand il peut voir que le programme a été conçu pour fonctionner sur une version de Windows qui a Aero.
Vous pouvez modifier le numéro de version et le ramener à 4.00 en cours d'exécution Editbin.exe sur vos assemblées avec le /sous-système de l'option. Cette réponse montre un exemple de postbuild événement.
C'est toutefois sur l'endroit où les bonnes nouvelles se termine, un problème important est que .NET 4.5 n'est pas très compatible avec .NET 4.0. De loin le plus grand raccrocher, c'est que les classes ont été déplacés à partir d'un assemblage à l'autre. Plus particulièrement, cela s'est passé pour l' [Extension] attribut. Précédemment dans System.Core.dll il s'est déplacé à 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 regarder dans Mscorlib pour l'attribut, activé par un [TypeForwardedTo] attribut dans la .NET 4.5 version du Système.Base de référence de l'assemblée. Mais il n'est pas là lorsque vous exécutez votre programme .NET 4.0
Et bien sûr, il n'y a rien qui vous aide à arrêter à l'aide de classes et de méthodes qui ne sont disponibles que sur .NET 4.0. Lorsque vous le faites, votre programme va échouer avec un TypeLoadException ou MissingMethodException lorsqu'il est exécuté sur 4.0
Juste cible 4.0 et tous ces problèmes disparaissent. Ou briser cette impasse et arrêter le support de XP, une décision d'affaires que les programmeurs ne font souvent, mais nous pouvons certainement encourager en pointant du doigt les tracas qu'il est à l'origine. Il y a bien sûr un non-zéro coût d'avoir à aider les anciens systèmes d'exploitation, juste de l'effort de test est important. Un coût qui n'est pas souvent reconnu par la direction, de compatibilité de Windows est légendaire, sauf s'il est indiqué. Avant que le coût pour le client et ils ont tendance à prendre la bonne décision beaucoup plus rapide :) Mais nous ne pouvons pas vous aider avec ça.
