InstallShield CustomAction: Как загрузить управляемые сборки зависимостей

Question

У меня есть базовая установка MSI InstallShield с управляемым настраиваемым действием EXE-файла, запущенным из двоичной таблицы. Я попробовал простой тест, который просто запускает консоль и работает нормально. Когда я добавляю ссылку на сборку.DLL в EXE, он не может найти DLL. Как сделать так, чтобы InstallShield знал об этой сборке, на которую он ссылается, чтобы она могла загружаться с EXE-файлом?

Answer 1

Пользовательские действия извлекают только один файл во временную папку под временным именем. Чтобы зависимость от.dll работала, их нужно извлечь, и, по крайней мере,.dll должен иметь ожидаемое имя. Как правило, это проще всего сделать, добавив как "установочные файлы", так и ссылки [SUPPORTDIR]\your.exe для пользовательских действий.

Answer 2

Что ж, я добавлю подробности относительно Installshield 2014 о том, как он работает сегодня. Другие ответы могут быть одинаково правильными по сравнению с другими версиями installshield. Я вижу, что Майкл ответил с 2012 года, и с тех пор многое изменилось. Посмотрим.

Для вашей сборки.Net могут быть два типа зависимостей:

1. Управляется (написано на языке C# или VB.Net. В этом конкретном случае используется OP)
2. Неуправляемый или нативный (например, C++ dll, вызываемые через p/invoke). Вы не ссылаетесь на такие сборки в своем проекте C#, но они загружаются во время выполнения с помощью DllImport атрибут и четко определенный механизм поиска сборки.

Давайте разберемся с проблемой OP, которая связана с зависимостью от управляемых сборок:

Просто для всеобщей информации, что installshield внутренне имеет собственную базу данных. Таким образом, когда вы добавляете пользовательское действие (в базовом проекте MSI installshield), которое вызывает метод, присутствующий в управляемой сборке, все атрибуты пользовательских действий помещаются в виде записей в ISClrWrap таблица внутренней базы данных, как показано ниже:

Теперь installshield не предоставляет никакого пользовательского интерфейса или прямого механизма, в котором мы можем определять зависимости ваших управляемых сборок (которые вы добавили в качестве ссылки в свой проект C# в Visual Studio). Но вы можете обновить эту таблицу базы данных, чтобы отразить то же самое. Вам нужно добавить одну запись для каждой новой зависимости в этой таблице. Для названия столбца вы должны выбрать Dependency0 для первой зависимости, Dependency1 для второй зависимости и так далее. Посмотрите на снимок ниже, как я это сделал после нажатия новой кнопки вверху для добавления новой записи:

После добавления всех ваших сборок управляемых зависимостей таблица начинает выглядеть так:

Вот и все. Вы сделали отсюда. Оставьте остальное для установки щита. Теперь методы присутствуют в MyManagedAssembly.dll сможет вызывать методы, присутствующие в MyManagedDependencyAssembly1.dll или же MyManagedDependencyAssembly2.dllв процессе установки.

Примечания:

1. Вам не нужно добавлять сборки управляемых зависимостей в файлы поддержки (путь которых представлен [SUPPORTDIR] имущество). То, как installshield управляет копированием управляемых сборок зависимостей в процессе установки, является его внутренней реализацией.
2. Зависимости вашего проекта C# (используются в пользовательских действиях) от базовых сборок.NET, которые являются частью.NET Framework FCL, например System.dll, Systen.Core.dll и т.д. не нужно добавлять в эту таблицу. Они загружаются по умолчанию, когда InstallShield загружает CLR для выполнения управляемого кода.

Answer 3

Я не мог найти достойный способ использовать пользовательские действия.Net, которые позволяли бы мне делать то, что я пытался сделать. В итоге я использовал раздел DTX (Deployment Tools Foundation) WiX для создания сборки, и она отлично работала.

Answer 4

Пожалуйста, добавьте свою DLL в качестве зависимости в двоичную таблицу isclrwrap. Вы можете найти эту двоичную таблицу в прямом редакторе. Это решит вашу проблему.