In talking with others, it appears that the NAnt vs. MSI deployment camps are pretty much split down the middle.  I tend to lean towards MSI deployments for several reasons.


When dealing with MSI packages, it is often necessary to go beyond the somewhat basic BTSInstaller project that comes with BizTalk.  I have posted before on custom actions to fill in the gaps that come with using the BTSInstaller.  Another thing to think about when using MSI deployment is what happens if BizTalk is not installed to the default install directory (it’s very common for enterprise clients to install software to a drive other than C:\).  If you are deploying pipeline components, this is important as they have to be copied to the Pipeline Components directory of the BTS install directory.  Another thing to keep in mind is if you create custom adapters.  The tricky part with custom adapters is that they require registry settings.  You can include a reg file for the installer to run, but it would be nicer to handle that for them.  Additionally, one of those registry settings is the path to the custom adapter component.  Again, you can’t be sure of the install directory of your components.


Luckily, it’s pretty easy to handle both of this situations following the steps below –


Determining the BizTalk install directory


This one turns out to be pretty easy as the BTS install directory gets stored in the registry.  And, the MSI install project gives us the ability to search the registry, so we just need to know what to search for.



  1. In the install project, right click and choose View|Launch Conditions.

  2. Name the launch condition BizTalk Install Path.

  3. Enter BIZTALKINSTALLPATH for the Property property.  We will use this property later.

  4. For the RegKey property, enter SOFTWARE\Microsoft\BizTalk Server\3.0.

  5. For the Root property, choose vsdrrHKLM from the dropdown.

  6. For the Value property, enter InstallPath.

Now that we have set up a launch condition to find the BizTalk install path, we can make use of that value in our install process.  For pipeline components, I like to add a new folder to the File System section of the install project and name it Pipeline Components.  In the DefaultLocation property of that folder, enter [BIZTALKINSTALLPATH]\Pipeline Components as the value.  You will notice [BIZTALKINSTALLPATH] is how we get to our properties of the install project.  It’s that easy.


Determining install path chosen during install process


For this section, I’m going to leave out most of the steps you need to take to add the registry settings to register your custom adapters.  Contact me if you need that information.  The easiest way to handle this is to run the wizard that creates the .reg file for you (you can find this tool on the web), and make sure you add all those keys in the Registry section of the install project.


Two properties to take particular note in are the AdapterMgmtAssemblyPath and the InboundAssemblyPath.  These properties point to specific paths of your components (generally the same component). So, we need to somehow capture where the installer has chosen to install our components, and then make use of this value.



  1. Right click on the installer project, and choose View|File System.

  2. Select the Application Folder folder on the left side.  Notice that the property (which is read only in this section) is set to TARGETDIR.  This is similar to our BIZTALKINSTALLPATH property that we created.

  3. Right click on the installer project, and choose View|Registry.  This is where you will enter all the keys and values you need for your custom adapters.  When you get to the AdapterMgmtAssemblyPath and the InboundAssemblyPath properties, you will prepend you assembly name with [TARGETDIR] and enter that for the value of the key.

Remember, when creating install packages, we want to make the install process as “painless” for the installer as possible.  These folks are typically not BizTalk people, and even worse, the process is usually automated.  Hopefully these little tips will make your MSI package creation a little easier.


Cheers,


Todd