Принудительно установить GAC перед запуском настраиваемого действия .NET?

Question

Я использую проект установки и развертывания VS 2008 для развертывания смешанного управляемого / неуправляемого приложения. У меня возникли проблемы при регистрации DLL в смешанном режиме с использованием встроенного свойства регистрации (перечисляемое значение «vsdraCOM» свойства «Register».) В качестве обходного пути я добавил сборку пользовательской установки .NET (с классом, который Происходит от System.Configuration.Install.Installer.) Я уверен, что этот класс работает, и ряд операций успешно устанавливаются и удаляются с помощью кода в этой сборке, включая выполнение точки входа Dll (Un) RegisterServer для ряда сборок. ,

Однако одна DLL не регистрируется успешно. Это единственная библиотека DLL, которая зависит от некоторых сторонних распространяемых сборок, которые нужно установить в GAC. Я установил эти сборки в GAC благодаря встроенной поддержке для этого в проектах установки и развертывания VS 2008, и я знаю, что это работает. Я подтвердил, что происходит то, что настраиваемое действие выполняется до того, как установщик выполнит установку GAC.

Уф. Итак, мой вопрос: есть ли способ заставить установщик выполнить установку GAC перед выполнением пользовательского действия? Есть ли способ использовать свойство «Condition» пользовательского действия для этого? Если нет, то какая моя лучшая альтернатива? Захватить записи реестра из DLL и добавить их в настройки реестра для установщика (не нравится это, потому что кто-то может добавить новые COM-серверы в класс в будущем)? Использование кода .NET для установки сборки в GAC вручную (пока не знаю, как это сделать)?

Спасибо

Dave

Answer 1

Проекты установки, которые вы можете создать в Visual Studio, очень ограничены. Это позволяет только настраиваемые действия планироваться в 4 точках. Однако MSI позволяет планировать настраиваемые действия в любой точке процесса с некоторыми ограничениями на то, что они могут делать.

Мое первое решение - перестать использовать Visual Studio 2008 в качестве инструмента разработки настроек. Команда Visual Studio пыталась абстрагироваться от всей сложности создания установки. Тем не менее, в процессе они также забрали всю гибкость MSI. Wix, InstallShield или Wise - намного лучшие продукты для чего угодно, кроме простой установки. Я начал использовать Visual Studio для наших установок, и это оказалось слишком большой работой. Всегда был еще один обходной путь, который нужно было реализовать, и его побочные эффекты.

Если вы не можете переключить технологию, вам нужно будет научиться вручную изменять полученный MSI-файл. В вашем случае вам потребуется изменить таблицу InstallExecuteSequence, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx.. Это можно сделать вручную через Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx или через MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx.. Убедитесь, что вы загрузили Orca и запустите сценарии проверки для вашей установки. Сценарии указывают на многочисленные проблемы, устранение которых позволит сэкономить бесчисленные часы при развертывании на клиентских компьютерах.