WPF замедляются для запуска на x64 в Платформе.NET 4.0
Я заметил, что, если я создаю свое приложение WPF для Какого-либо CPU/x64, оно берет НАМНОГО дольше, чтобы запуститься (на порядке приблизительно 20 секунд) или загрузить новые средства управления, чем оно делает, если запущено на x86 (в выпуске и режимах отладки, внутри или снаружи VS). Это происходит даже с самыми простыми приложениями WPF. Проблема обсуждена в этом потоке MSDN, но никакой ответ не был предоставлен там. Это происходит только с.NET 4.0 - в 3,5 SP1, x64 был так же быстр как x86. Интересно, Microsoft, кажется, знает об этой проблеме, так как значение по умолчанию для нового проекта WPF в VS2010 является x86.
Действительно ли это - реальная ошибка, или я просто делаю ее неправильно?
Править: Возможно связанный с этим: Медленное время установки Привязки данных в.NET C# 4.0. Я использую привязку данных в большой степени.
1 ответ
На самом деле есть 2 основные причины, по которым тип проекта по умолчанию для приложений WPF - x86.
- Отладка Intellitrace работает только с x86, и это выглядело бы очень плохо, если бы стандартные шаблоны проектов не работали с одной из их звездных функций.
- Многие разработчики все еще не знали о том, что их исполняемые файлы AnyCPU будут работать как x64 на 64-битных машинах, и были удивлены, обнаружив, что 32-битные библиотеки DLL, на которые они полагались, не существовали в 64-битных вариантах, таких как драйверы OLEDB, некоторые родные. DLL и т. Д.
Что касается проблем во время запуска, с которыми вы сталкиваетесь, это почти похоже на проблему с NGEN.Поскольку существуют разные кеши NGEN для процессов x64 и x86, может оказаться, что 64-битный кеш NGEN необходимо либо перестроить, либо обновить. Попробуйте выполнить следующую команду из командной строки с повышенными привилегиями:
CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update
Это команда для повторной сборки образов в машинном коде для сборок, которые уже были помечены для NGEN. Это также, вероятно, не принесет вам никакой пользы для вашего приложения NGEN, если сборки также не находятся в GAC, поэтому я бы не стал пытаться это сделать. Но сборки каркаса, сборки инструментальных средств и т. Д. Должны быть NGEN'ом.
(Между прочим, я получал несколько ошибок, когда запускал указанную выше команду о сборках, которые не могли быть загружены. В основном это были сборки SQL и Visual Studio.)