Archives par étiquette : Visual Studio 2010

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.

Process msiexec.exe qui tourne en permanence depuis l’installation de Visual Studio 2010 sur Windows 7 RC

Si vous avez installé la beta 1 de Visual Studio 2010 sur un Windows 7 RC, il est
possible que vous ayez deux process msiexec.exe qui tourne en permanence. Le problème
est que ces deux process peuvent prendre aléatoirement pas mal de CPU sur votre machine,
et surtout empêchent l’exécution de MSI qui vérifient si un autre programme d’installation
est en cours d’exécution.

Bien sûr il est inutile d’essayer de killer ces process via le gestionnaire des tâches
car ceux-ci ressusciteront très rapidement en causant toujours les mêmes désagréments.

Le problème est que le setup essaie de trouver une ressource dans le dossier C:Program
Files (x86)Microsoft Visual Studio 9.0Common7IDEPublicAssembliesen. Dossier
qu’il ne trouve pas.

Afin de résoudre le problème il vous faut donc :

  • Créer un dossier nommé “en” dans le dossier C:Program FilesMicrosoft
    Visual Studio 9.0Common7IDEPublicAssemblies
  • Copier le contenu du dossier PublicAssemblies dans ce dossier
    en
  • A présent quand vous killerer msiexec.exe, il ne reviendra plus
    dans tâches !

En savoir plus :

Explication
du bug et Workaround sur Connect