2015-06-11 1 views
0

Я уже много лет развертывал свои сборки .NET с помощью x-copy без каких-либо проблем. С прошлой недели у нас есть небольшая команда, у которой есть задача построить установку, которая включает в себя: .NET-сборки и exe и C++ legacy exe и dll (более 200 файлов). После первой установки у меня есть проблема с моим приложением wpf: время запуска очень велико. Я профилировал одно из своих приложений wpf (ps: .NET-сборки как GACed, так и NGened) с procmon , и я вижу, что процесс делает операции с множественными значениями (см. Прикрепленный скриншот) на всех других несвязанных (> 200) файлах и I думаю, что это основная причина медленного запуска приложения. Это связано с политикой издателя .NET? Как я могу отключить это поведение, чтобы сделать мое приложение снова быстрым? Спасибо заранее!Медленный запуск wpf из-за политики публикации ... возможно

enter image description here

ответ

1

Это множество следов, кажется, относится к COM конкретизации на основе «рекламировали» COM-классы. Не зная ничего о том, как ваша MSI организована в функции, компоненты и регистрацию COM, трудно быть абсолютно уверенным.

Но в любом случае, если классы COM зарегистрированы с использованием таблицы Class в файле MSI, то у них есть значение реестра InprocServer32 (НЕ ключ), называемый Darwin-дескриптором. Он ссылается на цель создания экземпляра COM через имя функции, код продукта и код компонента, и это может быть причиной того, что вы видите ссылки на функцию установщика Windows и ключи компонентов в реестре. Как правило, вызов MsiProvideComponent с этим дескриптором, в результате проверки устойчивости и ремонта, если что-то сломано.

Вы не говорите, какой инструмент вы используете, но если у вас много регистрации COM, и все это рекламируется посредством регистрации в таблице классов MSI, это может быть проблемой. Не зная, какой инструмент вы используете для сборки MSI и видите файл MSI, трудно быть уверенным. Но WiX, например, позволяет вам использовать таблицу Class для регистрации, но использовать Advertising = no, и это приводит к регистрации, выполняемой с использованием записей в реестре, что является довольно очевидным другим способом создания регистрации COM, при этом избегая проверки рекламы/отказоустойчивости.

Кроме того, возможно, самое главное, вам нужно убедиться, что установка вашего продукта на самом деле не восстанавливает себя, когда он запускается, что замедлит его! Если, например, любые файлы или элементы реестра удаляются после установки, может произойти ремонт. Ищите записи журнала событий MsiInstaller в журнале событий приложений, ссылаясь на отсутствующие компоненты.

+0

Привет @PhilDW, спасибо за подробный ответ. Сегодня я получил новости о том, что моя команда настройки использует Install Shield для создания файла msi. Есть опция в Install Shield, чтобы избежать проблем, описанных выше? – laertes

+0

Не знаю, извините, вам нужно посмотреть, есть ли опция, использующая такие термины, как «анонимная регистрация COM» или «использовать реестр вместо таблицы классов». – PhilDW