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

J'ai remarqué que si je créer mon application WPF pour n'Importe quel CPU/x64, il faut BEAUCOUP plus de temps à démarrer (de l'ordre d'environ 20 secondes) ou de charger de nouveaux contrôles qu'il ne s'commencé sur x86 (dans la version & modes de débogage, à l'intérieur ou à l'extérieur de la SV). Cela se produit même avec la plus simple des applications WPF. Le problème est discuté dans cette MSDN fil, mais aucune réponse n'a été fourni de là. Cela se produit uniquement avec .NET 4.0 -- en 3.5 SP1 x64 était rapide, comme x86. Il est intéressant de noter, Microsoft semble savoir à propos de ce problème, car la valeur par défaut pour un nouveau projet WPF dans VS2010 est x86.

Est-ce un réel bug ou suis-je seulement fait-il mal?

EDIT: Éventuellement liées à cela: Lent Databinding moment de l'installation dans C# .NET 4.0. Je suis l'aide de la liaison de données fortement.

InformationsquelleAutor Robert Fraser | 2010-06-01
  1. 72

    Fait, il y a 2 raisons principales que le type de projet par défaut pour les applications WPF est x86.

    • Intellitrace débogage ne fonctionne qu'avec les x86 et que serait un look assez mauvais si les modèles de projet par défaut ne fonctionne pas avec un seul de leurs cheveux.
    • De nombreux développeurs n'étaient pas encore conscients du fait que leur AnyCPU exe serait exécuté en tant x64 64 bits machines et ont été surpris de constater que 32 bits DLL elles ont invoqué n'existe pas en 64 bits des variétés telles que le OLEDB pilotes, certains natifs de DLL, etc.

    Que pour le temps de démarrage des problèmes que vous rencontrez, il semble presque comme un problème avec NGEN. Puisqu'il y a différentes NGEN caches x64 et x86 processus, il se pourrait que le 64 bits NGEN cache doit être reconstruit ou mis à jour. Essayez d'exécuter les opérations suivantes à partir d'une invite de commande élevée:

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

    C'est la commande de re-construire des images natives pour les assemblées qui ont déjà été marqués par NGEN. Elle aussi ne sera probablement pas vous faire du bien à NGEN votre demande si les assemblées ne sont pas également dans le GAC, donc je ne serait pas la peine d'essayer de le faire. Mais cadre des assemblées, les outils assemblées, etc devraient tous être NGEN avais.

    (En passant, j'ai eu plusieurs erreurs lorsque j'ai exécuté la commande ci-dessus sur les assemblys qui n'a pas pu être chargé. C'était surtout SQL et Visual Studio assemblées.)

    • SAINT -****, TRAVAILLÉ!!! Je n'aurais jamais compris. Vous vraiment à la hauteur de votre nom de famille, mec. Merci * 1000!
    • Grand, heureux de l'entendre.
    • Jeebus, ce conseil fonctionne à merveille! Comment diable ont-ils gérer pour ne pas garder de leur cache, up-to-date, de voir l'impact de cette? Gros fail pour MME Par le façon, il semble que vous avez besoin de refaire cette après l'installation de certaines mises à jour.
    • Juste pour confirmer, après quelques heures passées au débogage et à la recherche de cette bug, j'ai couru NGEN update et la demande a commencé à courir comme un diable!!! Merci beaucoup frère.
    • est-ce toujours d'actualité dans Windows 10? Et updated.Net la version?
    InformationsquelleAutor Josh