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.

Lorsque l’on installe la version 64 bits de Virtual PC 2007 sur un OS 64 bits, on est surpris de voir que le programme souhaite s’installer dans le dossier Program Files(x86) réservé aux applications 32 bits au lieu de s’installer dans le dossier Program Files où reposent les applis 64 bits. Il n’y aucune erreur dans l’installation, le fait est que Virtual PC 2007 64bits reste une application 32 bits mais qui utilise des drivers systèmes 64 bits.

Cependant le fait que Virtual PC reste 32 bits, a un impact important : vous avez beau avoir installé un 0S 64 bits et disposer de Virtual PC 64 bits, il ne vous sera pas possible d’installer un OS 64 bits en Guest dans une machine virtuelle ! Si vous tentez une telle installation vous vous retrouverez avec l’erreur suivante : “Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode” :

La même limite existe pour Windows Virtual PC (la version de VPC dédiée à Windows 7) ainsi que pour Virtual Server 2005 R2.

La seule solution possible proposée par Microsoft pour virtualiser du 64 bits est Hyper-V. A noter qu’il n’est pas conçu pour les notebooks et donc supporte assez mal les mode de veille ou d’hibernation.

Autre solution, se passer des solutions Microsoft et utiliser VMWare qui est même capable de faire tourner une machine virtuelle 64 bits dans un OS 32 bits.

Si vous allez changer d’OS (pour migrer vers Windows 7 par exemple) et souhaitez être sûr que votre machine supporte le 64 bits vous avez deux solutions simples.

Si votre CPU fait partie de ceux-cités dans le tableau suivant vous avez votre réponse :

Sinon, vous pouvez utiliser un utilitaire proposé par Intel nommé “Intel Processor Identification Utility” qui vous permettra d’avoir toutes sortes d’infos sur votre CPU comme par exemple celle du support du 64 bits :

Disposer d'une machine virtuelle et d'une compilation en deux phases permet de bénéficier d'un support du 64 bits quasi-automatique. Si l'on compile une assembly en Any Cpu, celle-ci sera compilée en JIT en 32 bits si elle est chargée dans un process 32 bits ou en 64 bits dans le cas d'un chargement dans un process 64 bits. De plus si une assembly a des dépendances vers des assemblys 32 bits ou vers des DLL natives 32 bits,  elle se retrouvera automatiquement compilée en 32 bits même si chargée dans un environnement 64 bits.

Il faut cependant noter que cette analyse de dépendances ne concerne que les dépendances statiques et en aucun cas les dépendances dynamiques (introduites via du code).

J'ai récemment rencontré le problème à propos de l'utilisation d'un filtre DirectShow. Le filtre est instancié via un Activator.CreateInstance afin d'être manipulé et insérer au sein d'un graphe de cette manière :

    /// <summary>
    /// Wrapper of the HttpDestinationFilter
    /// </summary>
    public class HttpDestinationFilter
    {
        private static readonly Guid CLSID_HttpDestination = new Guid("E6788379-AAA3-4516-86EC-158B7A49EA74");

        public static IBaseFilter CreateInstance()
        {
            return (IBaseFilter) Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID_HttpDestination, true));
        }
    }

Seul problème, lors de l'exécution de ce code sur une plate-forme 64 bits, l'instanciation peut échouer si le composant en question est en 32 bits et si l'assembly est compilée en Any Cpu.

Etant sur un Windows 64 bits, la base de registres est en grande partie divisée en deux versions, une copie pour les applications 32 bits et une autre copie pour les application 64 bits. Il est ainsi (entre autres raisons) impossible d'utiliser des composants COM 32 bits depuis une application 64 bits car le composant se retrouve introuvable du fait de la redirection. La correction du problème est simple : trouver une version 64 bits du composant en question ou alors définir manuellement la target de compilation afin d'indiquer un compilation en 32 bits.