Lorsque je crée une nouvelle application WPF dans Visual Studio 2012, la cible de plate-forme et la configuration de construction sont définies sur x86 par défaut. Pourquoi est-ce le cas ? Pour une simple application WPF (sans aucune référence à des assemblages en mode mixte), y a-t-il un danger à utiliser AnyCPU pour que mon exécutable WPF soit transformé en code x64 sur ma machine x64 et en x86 sur une machine x86 ?
Réponses
Trop de publicités?
Pourquoi en est-il ainsi ?
Pour la plupart des applications, il est préférable de construire en 32 bits. Le 64 bits offre peu d'avantages et présente des inconvénients importants dans la plupart des cas (utilisation beaucoup plus importante de la mémoire, gestion plus complexe des dépendances avec des plates-formes multiples, expérience de débogage moins bonne, etc.)
Si, toutefois, votre demande besoins pour pouvoir utiliser de grandes quantités de mémoire, alors bien sûr le 64 bits a des avantages (et il est facile de le changer dans VS), mais la plupart des applications ne sont pas dans ce cas.
C'est pourquoi la nouvelle valeur par défaut dans VS 2012 est d'utiliser AnyCPUPrefer32Bit au lieu de AnyCPU pour les applications.
Joel Rondeau
Points
4467
Selon cette rapport de bogue Cela a été fait à cause de problèmes avec Edit and Continue sur des machines x64 avec du code x64. En le changeant en x86, Edit and Continue fonctionne correctement.
Il ne devrait pas y avoir de danger à le basculer sur AnyCPU. Je fais toujours cela.
paulsm4
Points
39422
Si vous choisissez de spécifier une unité centrale, vous limitez automatiquement votre fichier .exe à une plate-forme ou à une autre.
Il y a rarement une raison de le faire, sauf si vous avez absolument des dépendances 32 bits :
En d'autres termes, il n'y a pas de problème de "performance". Le vrai problème est la "compatibilité". Si vous chargez des composants 32 bits et que vous êtes sur une plate-forme 64 bits, vous devez invoquer WOW64. CLRTIMAGETYPE vous permet de le faire.
