WPF медленно запускается на x64 в .NET Framework 4.0

Я заметил, что если я создам свое приложение WPF для Any CPU/x64, ему потребуется больше времени для запуска (порядка 20 секунд) или для загрузки новых элементов управления, чем при запуске на x86 (в выпуске и режима отладки, внутри или снаружи VS). Это происходит даже с простейшими приложениями WPF. Проблема обсуждается в этот поток MSDN, но ответа там не было. Это происходит только с .NET 4.0 - в 3.5 SP1, x64 был так же быстро, как и x86. Интересно, что Microsoft, похоже, знает об этой проблеме, поскольку по умолчанию для нового проекта WPF в VS2010 является x86.

Является ли это настоящей ошибкой или я просто делаю это неправильно?

EDIT: Возможно, связано с этим: Медленное время настройки привязки данных в С#.NET 4.0. Я сильно использую привязку данных.

Ответ 1

На самом деле есть две основные причины, по которым тип проекта по умолчанию для приложений WPF - это x86.

Отладка Intellitrace работает только с x86, и это выглядело бы неплохо, если шаблоны проектов по умолчанию не работали с одной из их звездных функций.
Многие разработчики до сих пор не знали о том, что их AnyCPU exe будет работать как x64 на 64-битных машинах и с удивлением обнаружил, что 32-разрядная DLL, на которую они ссылались, не существовала в 64-битных вариантах, таких как драйверы OLEDB, некоторые родные DLL и т.д.

Что касается проблем времени запуска, которые вы испытываете, это почти похоже на проблему с NGEN. Поскольку для x64 и x86 существуют различные кэши для NGEN, может быть, необходимо, чтобы 64-разрядный кэш NGEN нужно было перестроить или обновить. Попробуйте выполнить следующее из командной строки с повышенными правами:

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

Это команда для повторной сборки собственных изображений для сборок, уже отмеченных для NGEN. Это также, вероятно, не принесет вам пользы для NGEN вашего приложения, если сборки не находятся в GAC, поэтому я бы не стал пытаться это сделать. Но рамки сборки, сборки инструментальных средств и т.д. Должны быть NGEN'd.

(Кстати, я получил несколько ошибок, когда я выполнил приведенную выше команду о сборках, которые не могли быть загружены. В основном это сборки SQL и Visual Studio.)