Est-il possible d'exécuter une application .NET 4.5 sur XP?

86

Tout d'abord, j'ai lu ce qui suit:

Donc, à partir de la dernière puce, je pense vraiment qu'il n'y a aucun moyen de contourner cela, mais j'ai dû voir si je pouvais obtenir une réponse définitive car mon équipe aimerait passer de .NET 4.0 à .NET 4.5. Cependant, nous devons prendre en charge XP.

N'y a-t-il aucune possibilité de passer à .NET 4.5 si nous voulons prendre en charge XP?

La seule chose à laquelle je pourrais penser est de créer deux solutions distinctes, mais les bases de code devraient alors diverger si nous utilisions les fonctionnalités .NET 4.5.

Donc, je recherche une solution de contournement incroyable que je n'ai pas pu trouver et que d'autres connaissent peut-être déjà.

c# .net .net-4.0 compatibility .net-4.5 Justin Pihony
la source
9
Non, tu ne peux pas. Restez fidèle à 4.0 jusqu'à ce que XP meurt définitivement.
Federico Berasategui

Réponses:

188

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              // <=== here!!
               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.

Hans Passant
la source
2
Merci Hans, j'ai pensé qu'il y avait des changements de rupture. J'apprécie également la solution de contournement. Nous ne pouvons pas l'accepter pour les raisons que vous avez indiquées, mais c'est bon à savoir. Peut-être que XP disparaîtra pour de bon un jour ....
Justin Pihony
3
just the testing effort is substantial- c'est ce qui a amené notre direction à "permettre de supprimer le support XP".
Christoph Fink
Je sais que c'est une vieille publication - mais - @JustinPihony: Votre entreprise a-t-elle déjà pensé à installer un OS plus récent, puis à installer VMWare ou Virtual Box? Il est un peu tard pour Windows 7 - mais Microsoft a donné une installation virtuelle de Windows XP qui vous a permis de basculer entre 7 et XP. Juste une pensée. :-)
Mark Manning
@MarkManning ce n'était pas sous notre contrôle. Il était utilisé ailleurs.
Justin Pihony
1
@JustinPihony: Ah. Hmmmmm ...... Ma seule autre suggestion est une kluge. Capturez la version du système d'exploitation, puis configurez simplement toutes les fonctions de vos classes à mettre dans des tableaux (ou un tableau). Faites en sorte qu'une baie (ou une partie d'une baie) soit pour XP et l'autre pour les systèmes d'exploitation plus récents. Ensuite, tout ce dont vous avez besoin est une sorte de variable globale qui est utilisée pour désigner l'ensemble à utiliser. Les appels peuvent tous être identiques (ou se ressembler) mais un ensemble utilise NET40_ <FUNCTION> et les autres peuvent utiliser NET45_ <FUNCTION>. Ce serait un appel indirect à la fonction elle-même. Cela a-t-il du sens?
Mark Manning
21

Malheureusement, non, vous ne pouvez pas exécuter de programmes 4.5 sur XP.

Et le message pertinent de cette page Connect:

Publié par Microsoft le 23/03/2012 à 10:39
Merci pour le rapport. Ce comportement est inhérent à la conception de .NET Framework 4.5 Beta. Les systèmes d'exploitation minimum pris en charge sont Windows 7, Windows Server 2008 SP2 et Windows Server 2008 R2 SP1. Windows XP n'est pas un système d'exploitation pris en charge pour la version bêta.

Oztaco - Réintégrer Monica C.
la source
8

Le projet Mono a abandonné le support de Windows XP et a "oublié" de le mentionner. Bien qu'ils affirment toujours que Windows XP SP2 est la version minimale prise en charge, il s'agit en fait de Windows Vista.

La dernière version de Mono à prendre en charge Windows XP était la 3.2.3.

client
la source
7

Essayez mono:

http://www.go-mono.com/mono-downloads/download.html

Ce téléchargement fonctionne sur toutes les versions de Windows XP, 2003, Vista et Windows 7.

luiseduardohd
la source
2
Mono est plus lent que .NET, et bien qu'il possède la plupart des fonctionnalités de .NET 4.5, il lui manque certains composants majeurs comme WPF ( mono-project.com/Compatibility ). Vous pouvez donc utiliser Mono pour la prise en charge de XP s'il fournit tout ce dont vous avez besoin et que vous êtes d'accord avec les implications en termes de performances. Sur le plan positif, il ne devrait pas être nécessaire de créer une "version Mono" spéciale, la version normale de .NET 4.5 fonctionne généralement sous Mono, mais vous devez tester spécifiquement Mono pour vous assurer que vous êtes compatible.
Qwertie
2
J'ai essayé mono-3.12.1-gtksharp-2.12.26-win32-0.msi sous Windows XP SP3 et cela a échoué avec "mono.exe n'est pas une application Win32 valide" . J'ai également essayé mono-3.0.10-gtksharp-2.12.11-win32-0.exe qui a échoué avec "mono.exe - Point d'entrée introuvable. Le point d'entrée de procédure InterlockedCompareExchange64 n'a pas pu être localisé dans la bibliothèque de liens dynamiques KERNEL32 .dll " .
Cristian Ciupitu