Recently I found myself working on a BizTalk 2006 project that had been pre-configured to use a number of referenced assemblies that ultimately would be deployed to the GAC on the target BizTalk machine. Unfortunately I found that managing the versions and deployments of this configuration to be ‘problematic’ at best, so I’ve been giving some thought to how this might be done differently.
My basic requirements for this process are as follows:
- The process must allow for assemblies built in a separate solution
- The process must be easy for developers
- All environments (including developers machines) must be installed the same way
- Deployed assemblies must be versioned
This post describes how I went about achieving these goals – though I’m sure there must be other ways to do this as well.
Setting up the new Development / Deployment Process
Step 1 – Create a new Setup project
Create a new Visual Studio Installer project within your solution, and configure the following properties (along with any others you may feel you want to change).
|Version||1.0.0 (then increment for each build)|
The real key for me here is the RemovePreviousVersions option. If this is set to “False” then the developers will need to manually uninstall the previous package – regardless of whether they are installing an upgrade.
By setting this to “True”, we are encouraging the development team to remember to increment the version of the setup package every upgrade. Changing the version of the setup package at this stage may also prompt the developer to increment the assembly version as well.
Step 2 – Add all project output to the GAC
In the “File System” setup, add a new target folder for the Global Assembly Cache. This is done by simply right-clicking on “File System on Target Machine”, then selecting “Add Special Folder”, then “Global Assembly Cache Folder”.
Now that the GAC folder is included in the installation folders list, add the “Primary Output” of your assemblies.
Step 3 – Add all project output to the Application Folder.
Technically this step is not really required – BizTalk only reads the assemblies from the GAC, so why bother putting them in the application folder as well …
There is a reason though – Visual Studio 2005 doesn’t allow you to reference a custom assembly directly from the GAC, so in order to allow the BizTalk Solution references to be upgraded each time a new copy of the assemblies is installed it is much easier to copy the output to the file system as well as the GAC.
Step 4 – Compile the Installation File, and install on your BizTalk environment
Not much to be said about this step really: compile the installation file and install onto the BizTalk development environment. I found I was doing this step fairly frequently through the day as incremental changes to the assemblies were made – so it pays to keep a network share to the installation folder open if possible.
Note that if the developer forgets to increment the version number of the installation package the installation will be blocked at this point. This is the desired result, as we always want the version incremented!
Step 5 – Add assembly references to your BizTalk solution
Open your BizTalk solution and add references to the new assemblies directly from the application installation folder (typically c:\program files\your company\your product).
Step 6 – Deploy to TEST and PROD environments the same way
Now that we have a consistent package for the assemblies don’t forget to maintain that consistency across all deployment environments … not just your dev box!
Resulting Development Process
After the changes above have been implemented, the development process for on-going changes.
I’d be quite keen to hear about how others have approached this problem. I’m unsure what is considered a pragmatic best practice in this space – and I can already hear the developers shouting about the extra steps introduced here! Is there a better way to do this while still meeting the requirements listed at the top of this post?