WPF tarda en iniciarse en x64 en .NET Framework 4.0

Me he dado cuenta de que si construyo mi aplicación WPF para Cualquier CPU / x64, se necesita MUCHO más para comenzar (del orden de unos 20 segundos) o para cargar nuevos controles que si se inicia en x86 (en los modos de liberación y depuración) , dentro o fuera de VS). Esto ocurre incluso con las aplicaciones WPF más simples. El problema se trata en este hilo de MSDN , pero no se proporcionó ninguna respuesta. Esto sucede solo con .NET 4.0: en 3.5 SP1, x64 fue tan rápido como x86. Curiosamente, Microsoft parece saber acerca de este problema ya que el valor predeterminado para un nuevo proyecto de WPF en VS2010 es x86.

¿Es esto un error real o simplemente lo estoy haciendo mal?

EDITAR: Posiblemente relacionado con esto: Tiempo de configuración de enlace de datos lento en C # .NET 4.0 . Estoy utilizando datos vinculantes en gran medida.

En realidad, hay 2 razones principales por las que el tipo de proyecto predeterminado para las aplicaciones WPF es x86.

  • La depuración de Intellitrace solo funciona con x86 y se vería bastante mal si las plantillas de proyecto predeterminadas no funcionaran con una de sus características de estrella.
  • Muchos desarrolladores todavía no eran conscientes del hecho de que sus ejecutables AnyCPU se ejecutarían como x64 en máquinas de 64 bits y se sorprendieron al descubrir que los DLL de 32 bits en los que confiaban no existían en variedades de 64 bits como controladores OLEDB, ciertos DLL nativos, etc. .

En cuanto a los problemas de tiempo de inicio que está experimentando, casi parece un problema con NGEN. Dado que existen cachés NGEN diferentes para procesos x64 y x86, es posible que el caché NGEN de 64 bits necesite ser reconstruido o actualizado. Intente ejecutar lo siguiente desde un símbolo del sistema elevado:

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

Este es el comando para volver a generar imágenes nativas para ensamblajes que ya han sido marcados para NGEN. Probablemente tampoco le hará ningún bien a NGEN su aplicación si las asambleas no están también en el GAC así que no me molestaría en tratar de hacer eso. Pero las asambleas marco, conjuntos de herramientas, etc. deben ser NGEN’d.

(Por cierto, recibí varios errores cuando ejecuté el comando anterior sobre ensamblajes que no se pudieron cargar. Se trataba principalmente de ensamblados de SQL y Visual Studio.)