Reputation: 10296
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:
However, here are my issues:
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?
Upvotes: 9
Views: 5765
Reputation: 10274
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.
Upvotes: 9
Reputation: 3639
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.
Upvotes: 12