Почему в BizTalk файл MSI импортируется и устанавливается?

Question

Я работаю над проектом BizTalk и не понимаю причину необходимости установки (двойной щелчок) и импорта (используя консоль администрирования biztalk).

У меня есть проект BizTalk, и я добавил привязки к его ресурсам и экспортировал MSI-файл. Теперь я хочу установить приложение на другой сервер.

Насколько я могу судить, это то, что делает установка MSI:

1. Копирует файлы в файловую систему
2. Регистрирует сборки в GAC
3. Добавляет приложение в апплет "Установка и удаление программ"

Тем не менее, вот мои проблемы:

1. Установка с использованием msi не добавляет приложение в консоль администратора Biztalk. Нам нужно импортировать MSI.
2. Удаление с помощью msi не удаляет сборки из GAC. Он только удаляет файлы, которые он скопировал в файловую систему. Есть ли еще для удаления, чтобы удалить сборки GAC, а?
3. Если я просто импортирую MSI, я могу запустить мое приложение biztalk, и оно, кажется, работает нормально. В сочетании с проблемами № 1 и № 2, зачем вообще нужен MSI? Я вижу, что импорт не добавляет его в GAC, поэтому, если другие приложения зависят от него, они не будут работать.

Я уверен, что мне не хватает функций / конфигурации, которые предоставляет msi, но может кто-нибудь помочь мне понять, почему msi нужно и устанавливать, и импортировать в biztalk, и почему при удалении из системы он не удаляет полностью все, что он установил?

Answer 1

При развертывании решения BizTalk необходимо выполнить две операции.

Почему развертывание решений BizTalk является двухэтапным процессом?

1. Зарегистрируйте решение BizTalk в базе данных управления BizTalk
2. Установите артефакты и зависимости BizTalk в файловую систему

Во-первых, сборки BizTalk, составляющие ваше решение, должны быть зарегистрированы в базе данных управления BizTalk. Это позволит BizTalk узнать, какие схемы, карты, конвейеры и оркестровки доступны.

Это делается путем импорта пакета установщика Windows в BizTalk.

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

Поэтому операцию импорта необходимо выполнить один раз для всей группы BizTalk.

Во-вторых, сборки BizTalk, которые были зарегистрированы в BizTalk, должны где-то существовать физически. Поэтому они должны быть установлены в файловой системе.

Это можно сделать, дважды щелкнув пакет установщика Windows.

Обратите внимание, что операцию установки необходимо повторить на любом физическом сервере, который входит в группу BizTalk. А поскольку в базе данных управления BizTalk есть только одно определение того, какие сборки являются частью решения, это объясняет, почему сборки BizTalk должны быть установлены в глобальный кэш сборок (GAC).

Обратите внимание, что пока что правило простое:

• Сборки BizTalk должны быть установлены в GAC на каждом сервере в группе BizTalk
• Сборки BizTalk должны быть импортированы (или зарегистрированы) в базе данных управления BizTalk один раз

Однако мы имели дело только со сборками BizTalk. Все другие сборки или другие зависимости (определения бизнес-правил, COM-объекты, привязки, файлы конфигурации и т. Д.), Необходимые для решения BizTalk во время выполнения, не охватываются этой двухэтапной операцией.

Межсредовое развертывание

Однако при запуске решения эти зависимости также должны присутствовать на каждом сервере BizTalk соответствующим образом.

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

Почему сборки BizTalk не удаляются из GAC при удалении?

Как правило, сборки, зарегистрированные в глобальном кэше сборок, считаются общими ресурсами. Поэтому по соображениям безопасности сборки BizTalk не удаляются из GAC при удалении. Подумайте, что произойдет, если пользовательский конвейер BizTalk используется более чем одним приложением. В этом случае конвейер BizTalk должен быть частью отдельного общего приложения BizTalk. Удаление этого общего приложения BizTalk приведет к поломке всех других приложений, которые зависят от этого конвейера...

При добавлении ресурсов в базу данных управления BizTalk у вас есть выбор, чтобы сборки были установлены в GAC при импорте или во время установки. Я настоятельно рекомендую не использовать функцию " GacOnImport ", которая не имеет смысла в большинстве типичных многосерверных групп BizTalk.

Однако существует более простой и гибкий способ настроить то, что можно сделать для сборок BizTalk или других зависимостей, в отношении пакета установщика Windows. Это делается с помощью сценариев предварительной обработки и последующей обработки.

Эти сценарии позволяют запускать произвольные приложения четыре раза во время операций импорта / установки.

• Перед импортом
• После импорта
• Перед установкой
• После ввода

Если вы хотите, чтобы сборки удалялись из GAC при удалении, достаточно просто запланировать соответствующую командную строку на этапе "Перед установкой" операции.

Answer 2

Импорт файла MSI добавляет сборки из MSI в базу данных BizTalk. Как вы заявили, запуск MSI добавляет сборки в GAC. И то, и другое требуется для того, чтобы приложение BizTalk было "установлено". Только сборки BizTalk должны быть импортированы в базу данных управления BizTalk. Все библиотеки DLL, используемые BizTalk, должны находиться в GAC.

Может быть стоит взглянуть на http://msdn.microsoft.com/en-us/library/aa578463(v=BTS.10).aspx чтобы увидеть, что вы можете настроить поведение для установки и импорта для каждого ресурса в вашем Приложение BizTalk. Это позволит вам импортировать только MSI и иметь возможность добавлять сборки в базу данных, а также устанавливать их в GAC, оставляя вас без лишних помех в ваших компонентах "Установка и удаление программ".

Что касается того, почему библиотеки DLL не удаляются из GAC при удалении установленного MSI, я могу сказать вам, что это было сделано специально. Если вы посмотрите на эту страницу в MSDN http://msdn.microsoft.com/en-us/library/aa562001(v=bts.10).aspx то увидите, что это поведение описано как и ожидалось. Эта статья MSDN также содержит ссылку, в которой описано, как удалить сборку из GAC, в которой объясняется, как использовать сценарий постобработки, чтобы MSI фактически удалял ваши сборки из GAC при удалении MSI.