image

Légers changements autour du 64 bits et de Visual Studio 2010

image C’est
en lisant le premier chapitre de
la 3ème édition de CLR via C#
de
Jeffrey Richter que m’est revenu cette information qui a son importance lorsque l’on
souhaite le pourquoi du comment à propos du support du 64 bits.

Jeffrey Richter indique à juste titre que le compilateur C# compile par défaut les
assemblies en AnyCPU afin que celles-ci soient portables et compilées en 32 ou 64
bits par le compilateur JIT en fonction de la plate-forme sur laquelle on souhaite
exécuter l’application. Ceci est vrai, mais on pourrait penser que donc Visual Studio
compile également par défaut vos assemblies en AnyCPU.

Et cela était effectivement le cas avec les précédentes versions de Visual Studio,
mais il y a eu un changement de politique avec Visual Studio 2010 qui a eu lieu assez
récemment il me semble (probablement à partir de la RC).

Avec la dernière version de l’ide, les projets qui sont généralement des points
d’entrées applicatifs (les types de projets relatifs au GUI clients) sont par défaut
compilés en x86.
Ainsi si vous créez un projet Windows Forms, un projet WPF
ou une application Console vous pouvez constater que l’AnyCPU qui faisait loi jusqu’
présent à laisser place à une configuration en x86. Les projets ASP.net et les bibliothèques
de classes ne sont pas concernés et restent par défaut en AnyCPU.

Pourquoi ce changement alors que l’AnyCPU permet d’avoir des assemblys
multi-plateforme et donc portables ?

Tout simplement, parce que les développeurs ne font pas assez souvent de tests de
leurs applicatifs sur des environnements 32 bits ET 64 bits.
Si vous développez dans un environnement 32 bits, et que vous ne testez pas votre
application 64 bits vous risquez
d’avoir des problèmes si vous référencez des composants 32 bits
. En effet, votre
point d’entrée étant en AnyCPU votre application sera compilée en 64 bits et sera
donc incapables de charger des composants 32 bits.

Modifier le paramétrage par défaut afin de compiler en x86 les projets de types GUI
clients permet d’avoir des applications qui fonctionneront dans tous les cas puisque
elles seront (par défaut) exécutées en 32 bits même sur un OS 64 bits. Vous êtes toujours
libre de changer cette configuration vers un compilation en AnyCPU mais prenez bien
garde à vos dépendances.

Quand aux projets ASP.net, ceux-ci concernent des applications serveurs qui ont potentiellement
bien moins de chance d’avoir des dépendances vers des composants 32 bits, et les bibliothèque
de classes restent en AnyCPU afin de garder leur portabilité, le point d’entrée de
votre application étant l’élément clé indiquant si le process doit être en 32 ou 64
bits.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *