Как диагностировать / управлять адом DLL с помощью InstallShield?

Question

Мы используем InstallShield для создания установщиков для ряда очень похожих продуктов, каждый из которых имеет общие файлы, которые хранятся в фиксированных каталогах под нашим каталогом поставщиков. У нас есть проблема с адской библиотекой DLL, которую, как я думал, установщики должны решить.

Представьте, что продукты A и B оба имеют файл FOO, установленный в каталоге D. FOO не обязательно является DLL; это может быть любой файл.

В идеальном мире обе копии FOO идентичны, и когда оба продукта установлены, FOO получает (перезаписывает) в D, и все в порядке. И вот как это работает, когда все одинаково.

На практике A и B могут быть из разных поколений, поэтому на самом деле A имеет вариант FOO A (FOO_a), а B имеет вариант FOO_b. Теперь только один из FOO_a или FOO_b окажется в D, если оба продукта установлены, и, следовательно, один из A или B будет сбит с толку из-за неправильного файла.

Что бы я ожидал от установщиков (и InstallShield), так это то, что для каждого продукта P, установленного в системе, счетчик ссылок будет где-то храниться (реестр?) Для каждого установленного файла. Таким образом, когда A установлен и FOO (_a) размещен, FOO помечается как принадлежащий A, и счетчик ссылок установлен в 1. Если B теперь установлен с FOO_b, идентичным FOO_a, FOO должен быть помечен как принадлежащий также B и счетчик ссылок увеличивается. Если B установлен, а FOO_b отличается от FOO_a, я ожидаю, что установщик пожалуется, что несовместимые файлы FOO были предложены для установки, и установка должна быть прервана. Когда продукт будет деинсталлирован, я ожидаю, что счетчики ссылок для каждого установленного файла будут уменьшены, а установленный файл будет удален только тогда, когда счетчик ссылок станет равным нулю.

Это не то, что делает InstallShield. Он просто врезает FOO в целевой каталог во время установки. По сути, это то же самое, что и DLL-ад. Это предполагаемое поведение установщиков? InstallShield? Windows?

Мы думали, что ищем способ попросить InstallShield справиться с этим, но ничего не нашли. Я был бы рад, если бы кто-то сказал, где искать, чтобы настроить это правильно. Или InstallShield не может / не будет этого делать? [Если так, почему я даю им деньги?]

Answer 1

Если варианты FOO являются версионными и накапливаются должным образом (это является ключом ко всем технологиям установки, работающим в общих расположениях), и если ваш компонент является общим, он использует один и тот же GUID в обоих продуктах (если MSI) и разделяет один и тот жеместо установки, тогда все будет работать.Поскольку части этого списка условий не соответствуют действительности, различные плохие вещи могут и будут происходить;у некоторых есть обходные пути, а некоторые не восстанавливаются.

• Если место установки отличается, мало или ничего из этого не имеет значения, если только оба продукта не будут искать в одном и том же месте по какой-то другой причине.
• Если MSI и GUID отличаются (или содержимое компонента отличается), вы нарушили правила компонента.Это может привести к тому, что файлы не будут удалены при окончательном удалении, непредвиденным изменениям в исправлении или другим трудно предсказуемым результатам.
• Если файл не имеет правильной версии, невозможно узнать, когда его заменитьдругой.Вероятно, в некотором порядке новая установка будет работать со старой версией.Это может быть смягчено в MSI с сопутствующими файлами, если другой файл имеет должным образом увеличивающиеся версии.
• Если файл не является накопительным в отношении версий, вероятно, новая версия файла сломает другуюпотребитель этого.В этом сценарии вы не должны устанавливать его в общую папку.

Один размер подходит для всех, иногда он становится немного грязным, поэтому обычно проблемное пространство упрощается до того, которое можно устранить.В этом случае стоимость заключается в том, что все авторы установки должны следовать некоторым правилам, если они хотят четко определенного поведения.

Answer 2

Если вы не хотите, чтобы файлы были общими, почему вы размещаете их в одном каталоге?Я бы предпочел поместить их в другое место.Теперь предположим, что ваш FOO_a используется многими программами одной и той же версии, затем для FOO_b, который требуется вашей новой программой и другими, которые могут быть добавлены позже, добавьте еще один аналогичный общий каталог и назовите их, используя имена поколений или что-то в этом роде.

Answer 3

Никто не может начать отвечать на ваш вопрос, не зная, какую технологию установки вы используете.InstallShield - это продукт, который поддерживает множество различных платформ.

Windows отслеживает только общие ссылки на файлы DLL.(SharedDllCount).Установщик Windows (при условии, что вы даже используете его) также отслеживает количество ссылок Compoent.

Однако следует отметить (опять же ЕСЛИ вы используете Установщик Windows), что процесс определения стоимости файлакоторый решает перезаписать файл, на самом деле не имеет ничего общего с количеством ссылок.Счетчик ссылок вступает в силу при удалении.

Предполагая, что вы используете установщик Windows, взгляните на:

Правила управления версиями файлов

Также посмотрите на:

Что произойдет, если правила компонента будут нарушены?

Это * что-то, что установщик Windows и InstallShield знают, как с этим справиться, если вы правильно его реализуете.Любой язык программирования может быть использован ненадлежащим образом и злоупотреблен или нет.

Answer 4

Если вы действительно ищете решение, используйте отдельные библиотеки DLL.Это просто и надежно, и на самом деле об этом проще говорить (как вы продемонстрировали, упомянув FOO_a и FOO_b).Это также позволяет избежать сообщения об ошибке, которое бесполезно для ваших пользователей.

В Windows была схема подсчета ссылок для общих библиотек DLL, но она была условной, поэтому была ненадежной.Если у вас когда-нибудь был деинсталлятор, спросите, действительно ли вы хотите удалить общий компонент, теперь вы знаете, почему.

Answer 5

Я считаю, что вы правы в том, как работает подсчет ссылок, если вы имеете дело с установщиком, основанным исключительно на MSI (это поможет узнать, являются ли A и B базовыми проектами MSI или InstallScript).В любом случае, я бы проверил, что компоненты, содержащие FOO в проектах установки A и B, установили его в качестве файла ключей и установили для свойства Shared значение Yes.Это должно привести к правильному управлению подсчетом ссылок.

Относительно того, что должно произойти, когда вы запускаете установщик и у него более новая версия общего файла, насколько мне известно, это зависит главным образом от того, имеет ли файл версиюили нет, будь то более новая версия и свойства, такие как его последняя измененная временная метка.Если вы создаете установщик для B, который содержит FOO_b, который отличается от FOO_a, я не уверен, как InstallShield мог знать, что он сломает A (я могу ошибаться, может быть).Один из возможных обходных путей - использовать пользовательские действия, чтобы проверить, отличается ли FOO_b, и, если это так, сделать копию существующего в начале установки, а затем скопировать его обратно в конце процесса.