在 BizTalk 中，为什么要导入并安装 MSI 文件？
我正在开发一个 BizTalk 项目，但不明白需要安装（双击）和导入（使用 biztalk 管理控制台）的原因。
我有一个 BizTalk 项目，我添加了对其资源的绑定并导出了一个 msi 文件。现在我想在另一台服务器上安装该应用程序。
据我所知，MSI 安装的作用是：
- 将文件复制到文件系统
- 将程序集注册到 GAC
- 将应用程序添加到“添加/删除程序”小程序
但是，这是我的问题：
- 使用 msi 安装不会添加将应用程序连接到 Biztalk 管理控制台。我们需要导入msi。
- 使用 msi 卸载不会从 GAC 中删除程序集。它仅删除复制到文件系统的文件。是否可以通过卸载来删除 GAC 程序集？
- 如果我只导入 MSI，我就可以启动我的 biztalk 应用程序，并且它似乎运行良好。结合问题#1 和#2，为什么需要 MSI？我可以看到仅导入不会将其添加到 GAC，因此如果其他应用程序依赖于它，它们将无法工作。
我确信我缺少 msi 提供的功能/配置，但是有人可以帮助我理解为什么需要安装 msi 并将其导入 biztalk 以及为什么当您卸载时它不会完全卸载它安装的所有内容？
I'm working on a BizTalk project and don't understand the reason for both installing (double-clicking) and importing (using biztalk admin console) is needed.
I have a BizTalk project and I added bindings to it's resources and exported an msi file. Now I want to install the application on another server.
As far as I can tell this is what an MSI install does:
- Copies files to the file system
- Registers assemblies into the GAC
- Adds the Application to the Add/Remove programs applet
However, here are my issues:
- Installing using the msi doesn't add the application to the Biztalk admin console. We need to import the msi.
- Uninstalling using the msi doesn't remove the assemblies from the GAC. It only removes the files it copied to the file system. Is there away for the uninstall to remove the GAC assemblies as well?
- If I just import the MSI I'm able to start my biztalk application and it seems to run fine. Combined with issue #1 and #2 why is the MSI needed at all? I can see just importing doesn't add it to the GAC so if other applications depend on it they won't work.
I'm sure I'm missing features/configuration that the msi provides, but could someone help me understand why the msi needs to both be installed and imported into biztalk and why when you uninistall it does not fully uninstall everything it installed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
部署 BizTalk 解决方案时需要执行两项操作。
为什么部署 BizTalk 解决方案需要两步操作？
首先，组成解决方案的 BizTalk 程序集必须注册到 BizTalk 管理数据库BizTalk 管理数据库。这将使 BizTalk 知道哪些架构、映射、管道和编排可用。
这是通过将 Windows Installer 包导入到 BizTalk 来完成的。
请记住，典型的 BizTalk 平台通常由许多物理服务器组成。但是，BizTalk 组中的所有服务器共享一个BizTalk 管理数据库。
因此，需要为整个 BizTalk 组执行一次导入操作。
其次，已注册到 BizTalk 的 BizTalk 程序集需要物理存在于某处。因此，必须将它们安装到文件系统中。
这是通过双击 Windows Installer 包来完成的。
请注意，需要在属于 BizTalk 组的任何物理服务器上重复安装操作。由于 BizTalk 管理数据库中对于哪些程序集是解决方案的一部分只有一个定义，这解释了为什么 BizTalk 程序集必须安装到全局程序集缓存 (GAC) 中。
请注意，到目前为止，规则很简单：
但是，我们只处理了 BizTalk 程序集。此两步操作不涵盖 BizTalk 解决方案在运行时所需的所有其他程序集或其他依赖项（业务规则定义、COM 对象、绑定、配置文件等）。
环境间部署
但是，当解决方案运行时，这些依赖项也必须相应地存在于每个 BizTalk 服务器上。
这就是为什么大多数这些工件也注册到 BizTalk 管理数据库的原因。但这一次，这样做只是为了在创建 BizTalk 解决方案的 Windows Installer 包时引入依赖项，以便可以将这些依赖项正确安装在目标服务器上。
为什么 BizTalk 程序集在卸载时不会从 GAC 中删除？
作为一般经验法则，注册到全局程序集缓存的程序集被视为共享资源。因此，出于安全原因，BizTalk 程序集在卸载时不会从 GAC 中删除。考虑一下当多个应用程序使用自定义 BizTalk 管道时会发生什么情况。在这种情况下，BizTalk 管道必须是单独的通用 BizTalk 应用程序的一部分。卸载此共享 BizTalk 应用程序将破坏依赖此管道的所有其他应用程序
... aspx">将资源添加到 BizTalk 管理数据库，您可以选择在导入或安装时将程序集安装到 GAC。我强烈建议不要使用“GacOnImport”功能，< strong>这在大多数典型的多服务器 BizTalk 组中没有意义。
但是，对于 Windows Installer 包，有一种更简单、最灵活的方法来自定义对 BizTalk 程序集或其他依赖项可以执行的操作。这是通过预处理和后处理脚本完成的。
这些脚本允许在导入/安装操作期间在四个特定时间运行任意应用程序。
如果您希望在卸载时从 GAC 中删除程序集，只需在操作的“安装之前”阶段安排适当的命令行即可。
Two operations need to be undertaken when deploying a BizTalk solution.
Why Deploying BizTalk Solutions is a Two-Step Operations?
First, BizTalk assemblies that comprise your solution must be registered to the BizTalk Management Database. This will allow BizTalk to know what Schemas, Maps, Pipelines and Orchestrations are available.
This is done by Importing your Windows Installer package to BizTalk.
Please, remember that a typical BizTalk plaform usually consists of many physical servers. However, all the servers in the BizTalk Group share a single BizTalk Management Database.
Therefore, the import operation needs to be done once for the whole BizTalk Group.
Second, the BizTalk assemblies that have been registered to BizTalk need to physically exist somewhere. Therefore, they must be installed to the file system.
This is done by double-clicking the Windows Installer package.
Notice that the install operation needs to be repeated on any physical server that is part of the BizTalk Group. And since, there is only one definition in the BizTalk Management Database as to what assemblies are part of the solution, this explains why BizTalk assemblies must be installed to the Global Assembly Cache (GAC).
Notice that, so far, the rule is simple :
However, we have only dealt with BizTalk assemblies. All other assemblies or other dependencies (Business Rules definitions, COM objects, bindings, configuration files, etc.) that a BizTalk solution needs at runtime are not covered by this two-step operation.
Inter-Environment Deployment
However, when the solution runs, those dependencies must also be present on each BizTalk server as appropriate.
That is why most of those artefacts are also registered to the BizTalk Management Database. But this time, this is only done so that the dependencies are brought in when the Windows Installer package for a BizTalk solution is created, and so that those dependencies can be installed appropriately on the target servers.
Why BizTalk Assemblies are Not Removed from the GAC upon Uninstall?
As a general rule of thumb, assemblies that are registered to the Global Assembly Cache are considered shared resources. Therefore, for safety reasons, BizTalk assemblies are not removed from the GAC upon uninstall. Consider what would happen when a custom BizTalk pipeline is used by more than one application. In that case, the BizTalk pipeline must be part of a separate, common, BizTalk application. Uninstalling this shared BizTalk application would break all other applications that depend on this pipeline...
When adding resources to the BizTalk Management Database, you have the choice to have assemblies be installed to the GAC at import or at install time. I strongly recommend against using the "GacOnImport" feature, that does not make sense in most typical multi-server BizTalk Groups.
However, there is an easier and most flexible way to customize what can be done to BizTalk assemblies or other dependencies, with regards to the Windows Installer package. This is done with Pre Processing and Post Processing Scripts.
Those scripts allow for running arbitrary applications at four specific times during the import/installation operations.
If you want assemblies to be removed from the GAC upon uninstall, it is a simple matter of scheduling the appropriate command-line during the "Before Installing" phase of the operation.
导入 MSI 文件会将程序集从 MSI 添加到 BizTalk 数据库中。正如您所说，运行 MSI 会将程序集添加到 GAC。两者都是“安装”BizTalk 应用程序所必需的。只需将 BizTalk 程序集导入到 BizTalk 管理数据库中。 BizTalk 使用的所有 DLL 都必须位于 GAC 中。
可能值得一看 http://msdn .microsoft.com/en-us/library/aa578463(v=BTS.10).aspx 查看您可以自定义 BizTalk 应用程序中每个资源的安装和导入行为。这将允许您仅导入 MSI，并将程序集添加到数据库并将它们安装到 GAC 中，从而使您的“添加/删除程序”中不会出现额外的混乱。
至于为什么当您卸载已安装的 MSI 时，DLL 没有从 GAC 中删除，我可以告诉您这是设计使然。如果您在 MSDN http: //msdn.microsoft.com/en-us/library/aa562001(v=bts.10).aspx 您可以看到此行为是按预期描述的。该 MSDN 文章还包括如何从 GAC 中删除程序集下的链接，该链接解释了如何使用后处理脚本让 MSI 在卸载 MSI 时实际从 GAC 中删除程序集。
Importing the MSI file adds the assemblies from the MSI into the BizTalk database. As you stated, running the MSI adds the assemblies to the GAC. Both are requires for the BizTalk application to be "installed". Only BizTalk assemblies have to be imported onto the BizTalk management database. All DLLs used by BizTalk must be in the GAC.
It may be worth a look at http://msdn.microsoft.com/en-us/library/aa578463(v=BTS.10).aspx to see that you can customize the behavior for install and import for each resource in your BizTalk application. This will allow you to only import the MSI and have that both add the assemblies to the database and install them in the GAC as well, leaving you without additional clutter in your Add/Remove Programs.
As to why the DLLs aren't removed from the GAC when you uninstall an installed MSI, I can tell you that this was by design. If you take a look at this page on MSDN http://msdn.microsoft.com/en-us/library/aa562001(v=bts.10).aspx you can see that this behavior is described as expected. That MSDN article also includes the link, under how to remove an assembly from the GAC, which explains how to use a post-processing script to have your MSI actually remove your assemblies from the GAC upon uninstall of the MSI.