Je me suis trompé dans ma première réponse. Ma première suggestion était de fabriquer une cale "version lie" pour votre application. Mais vous ne pouvez pas, parce que vous utilisez une application à code géré. Je ne dis pas qu'il n'est pas possible d'écrire des crochets d'API pour les applications .NET, mais la prise en charge des shims par appcompat semble être beaucoup plus ponctuelle pour les applications gérées.
Les shims d'application mettent en œuvre des redirections d'API de sorte que lorsque l'application effectue un certain appel d'API, celui-ci est intercepté ou "détourné" et d'autres données sont renvoyées à l'application par le shim.
http://technet.microsoft.com/en-us/library/dd837644(v=WS.10).aspx
L'infrastructure Shim met en œuvre une forme de programmation d'applications d'application (API). Plus précisément, elle exploite la nature de l'interface pour rediriger les appels d'API de Windows vers d'autres systèmes de code alternatif - le shim lui-même.
La plupart du temps, vous pouvez créer vos propres cales avec l'Application Compatibility Toolkit :
http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx
![AppCompat Toolkit]()
Le cas d'utilisation le plus courant des shims appcompat est celui du "mensonge de version", où le shim ment à l'application sur la version qu'elle utilise.
Parce que les développeurs insister de faire des contrôles de version dans leur code, ce qui est une erreur. Microsoft vous dit que c'est faux. Ne faites pas de contrôles de version dans votre code. (Vérifiez plutôt l'existence ou l'absence d'une fonctionnalité particulière que vous avez l'intention d'utiliser).
Mais les développeurs continuent à vérifier les versions tous les jours. Le pire, c'est qu'ils procèdent à des vérifications de version "==", c'est-à-dire que l'application ne fonctionnera pas si vous n'exécutez pas une version "==". exactes version de Windows, ce qui est arbitraire et stupide.
Soupir... développeurs.
Chris Jackson, de Microsoft, travaille sur la compatibilité des applications depuis de nombreuses années, et son attitude est similaire :
L'une des catégories de cales d'épaisseur que l'on trouve dans les pays en voie de développement est la cale d'épaisseur. sont les cales de mensonge. Essentiellement, nous avons des cales qui peuvent [ ] de développeurs ont été livrés avec une touche > défectueuse (et le taux de défaillance de cette touche sur les claviers de développeurs est étonnant). sur les claviers de développeurs est étonnant). Elles fonctionnent en renvoyant simplement un une valeur différente de l'API GetVersion(Ex), en fonction du système d'exploitation choisi. système d'exploitation sélectionné.
Mais malheureusement dans ce même article Il nous donne ce que je crois être l'élément d'information essentiel ici :
OK, maintenant que CompatAdmin est lancé, sous le menu Système Base de données, développez la liste des correctifs de compatibilité. Avec le commutateur /x, vous remarquerez que le fichier WinXPSP2VersionLie comporte désormais un signe plus. si vous le développez, vous verrez une liste de modules qui ont un losange rouge à côté de leur nom. à côté. Il s'agit de modules que cette cale exclut spécifiquement. Parmi ces Parmi ceux-ci ? Les modules .NET Framework.
Vous voyez, le .NET Framework n'aime pas trop qu'on lui mente. Il effectue des vérifications de version pour déterminer comment mettre en œuvre certaines choses, et penser qu'ils fonctionnent à un niveau inférieur n'est pas très bien. C'est pourquoi nous excluons intentionnellement ces modules et, par conséquent, nous excluons intentionnellement le code que vous écrivez et que ces modules sont en train d'exécuter. Ce n'est pas que nous voulions le faire, mais l' l'infrastructure ne nous a pas donné un bon moyen de les séparer. Nous avons soit nous avons menti à tout, soit nous n'avons menti à rien. Il était pire de mentir à tout, alors nous ne l'avons pas fait.
Héhé, c'est assez drôle que .NET fasse aussi des vérifications de version alors que je viens de dire à quel point c'était une mauvaise idée...
Pour les applications réelles qui est gérée, vous devrez modifier le code. Il s'agit là de quelque chose que vous ne pouvez pas, et ne devriez pas, shimper. quelque chose que vous ne pouvez pas, et ne devriez pas, shimper.
Ainsi, si vous remarquez que la ligne de version ne fonctionne pas, et que l'application l'application est gérée, alors mon petit doigt me dit que vous essayez de la caler avec un mensonge de version XP - et ça ne va pas marcher.
De MSDN :
En règle générale, les applications ne doivent pas vérifier la version du système d'exploitation. Si une application une application a besoin d'une fonctionnalité spécifique, il est préférable d'essayer de la trouver et de n'échouer que si elle est manquante. et de n'échouer que si la fonctionnalité nécessaire est manquante.
