As much as I am a fan of the Business Rules Engine (BRE) shipped with BizTalk Server there are times when I think it could use some more love from our friends at Microsoft, and never have I felt this more so than during a recent deployment exercise. I was aiming to deploy BRE Policies that made use of .NET based facts via BizTalk MSIs and I ran into the below problems which have made me somewhat rethink how I will carry out deployments of BRE Policies in the future.

  • You can’t import MSIs containing BRE Policies which make use of .NET classes into the BizTalk Runtime until those .NET assemblies have already been added to the GAC. This is fair enough, but once you’ve added the assemblies to the GAC you need to remember to close and reopen the BizTalk Administration console before you try to import the MSI or the MMC will not acknowledge that the assemblies are now in the GAC as seen in the below screenshot. This isn’t the biggest of deals, but it does push you towards installing your MSIs before importing them, which is the opposite of what I’ve seen most BizTalk administrators do.
Unable to locate assembly

Could not load file or assembly or one of its dependencies

  • The second problem which is much worse is that if the fully qualified namespace of the .NET classes that are used to make up your BRE Vocabularies are long enough then you will encounter the below error during installation of the MSI claiming that the fully qualified file name must be less that 260 characters. This is fair enough, however the problem is exacerbated by the fact that BizTalk creates a very complex folder structure when it writes the vocabularies to the file system during the MSI install process. I don’t think that breaking away from namespace standards at an organization to hack your MSI deployments as an acceptable solution so I needed to find another deployment pattern.

File path too long

I like that MSIs make our lives a lot easier during BizTalk deployments and I didn’t want to veer far away from this model when working out a solution. What I decided was that I was going to export my BRE Policies into a separate MSI, containing only the BRE policies and nothing else. I then added that MSI as a resource in my BizTalk application. Next up I created a .cmd file which calls on the BTSTask command during MSI installs (see my previous post regarding selectively executing pre/post processing scripts if you want to understand how this works) to deploy the BRE Policies MSI into the BizTalk Runtime, the contents of the file being as below.

If “%BTAD_InstallMode%” == “Install” If “%BTAD_ChangeRequestAction%” == “Update” (“C:\Program Files (x86)\Microsoft BizTalk Server 2010\BTSTask.exe” ImportApp /Package:”C:\Program Files (x86)\Generated by BizTalk\AppName\AppName BRE.msi” /ApplicationName:AppName /Overwrite)

I then added this .cmd file as a resource in BizTalk as well and the file type to Post Processing. An MSI can now be exported for the entire application excluding the BRE Policies which are contained within the BRE Policy only MSI.

The deployment flow is now as below.

  • The deployer installs the full-application MSI file first (if this is not a first time release then they might want to stop the application using the BizTalk Administration Console or through some other means, depending whether there are orchestrations involved or not / whether they are overwriting existing policy versions).
    • First the .NET assemblies are added to the GAC by the MSI install, including any within the contained application which the BRE Policy might be dependant on.
    • The post processing script will then deploy the BRE Policy only MSI to the BizTalk runtime, thus publishing the BRE Policies. Because we are not doing this via the BizTalk Administration console there is no need to close and reopen the MMC. Since the BRE Policies are not contained within the full-application MSI but only in the BRE policy MSI (which is only being imported, not installed), we will not run into the greater than 260 character issue.
  • The deployer then imports the full-application MSI through the BizTalk Administration console, restarts host instances, starts the application etc….

This isn’t the only way to work around these problems, but it does work. If anyone has any other ideas please do let me know.