WPF lent à démarrer sur x64 dans .NET Framework 4.0

Question

J'ai remarqué que si je construis mon application WPF pour Any CPU/x64, elle prend BEAUCOUP plus de temps à démarrer (de l'ordre d'environ 20 secondes) ou à charger de nouveaux contrôles que si elle est lancée sur x86 (en modes release et debug, à l'intérieur ou à l'extérieur de VS). Cela se produit même avec les applications WPF les plus simples. Le problème est abordé dans ce fil MSDN mais aucune réponse n'a été apportée. Cela ne se produit qu'avec .NET 4.0 - dans la version 3.5 SP1, x64 était aussi rapide que x86. Il est intéressant de noter que Microsoft semble être au courant de ce problème puisque la valeur par défaut d'un nouveau projet WPF dans VS2010 est x86.

S'agit-il d'un véritable bogue ou est-ce que je m'y prends mal ?

EDIT : Peut-être en rapport avec cela : Temps d'installation lent du Databinding en C# .NET 4.0 . J'utilise beaucoup la liaison de données.

Answer 1

En fait, il y a deux raisons principales pour lesquelles le type de projet par défaut pour les applications WPF est x86.

• Le débogage Intellitrace ne fonctionne qu'avec x86 et ce serait plutôt mal vu si les modèles de projet par défaut ne fonctionnaient pas avec l'une de leurs fonctionnalités phares.
• De nombreux développeurs n'étaient pas encore conscients du fait que leurs exe AnyCPU fonctionneraient en x64 sur des machines 64 bits et ont été surpris de constater que les DLL 32 bits dont ils dépendaient n'existaient pas en 64 bits, comme les pilotes OLEDB, certaines DLL natives, etc.

En ce qui concerne les problèmes de temps de démarrage que vous rencontrez, il semble qu'il s'agisse d'un problème avec NGEN. Comme il existe des caches NGEN différents pour les processus x64 et x86, il se peut que le cache NGEN 64 bits doive être reconstruit ou mis à jour. Essayez d'exécuter la commande suivante à partir d'une invite de commande élevée :

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update

Il s'agit de la commande permettant de reconstruire les images natives pour les assemblages qui ont déjà été marqués pour le NGEN. Cela ne vous servira probablement à rien de NGEN pour votre application si les assemblages ne sont pas également dans le GAC, donc je ne m'embêterais pas à essayer de le faire. Mais les assemblages de framework, les assemblages de toolkit, etc. devraient tous être marqués NGEN.

(À propos, j'ai obtenu plusieurs erreurs lorsque j'ai exécuté la commande ci-dessus concernant des assemblages qui ne pouvaient pas être chargés. Il s'agissait principalement d'assemblages SQL et Visual Studio).