OK, we've built our little BizTalk solution according to the latest “best practices”, putting standard schemas in one project, solution related schemas and maps in another project and our custom pipelines in a third project. We've build these in “Development” configuration and tested every possible combination of failures including parsing errors, mapping errors, transmission errors and even (old reliable) human error! We've configured our receive and send ports and HAT for maximum safety (no lost documents - or else!). We've reviewed possible security threats and created backups of backups of backups. Finally, we've exported our assembly binding to a file after selecting “Export items not associated with any assembly:” (this is important since we are not using an Orchestration in our solution) and made the required modifications for our target server.
So... we change our configuration from “Development“ to “Deployment“ and build each project IN REVERSE ORDER OF DEPENDENCY, changing our References to point to the “Deployment“ version of each dependent assembly as shown in Figure 1.

Figure 1: Assembly Dependencies
Now we're ready to deploy our simple BizTalk solution in a simple manner!
1. We copy our assemblies to our target server, placing them in a folder such as C:\BizTalk Assemblies.
2. We deploy each assembly using the BizTalk Deployment Wizard IN REVERSE ORDER OF DEPENDENCY.
3. We import our BizTalk assembly binding FOR OUR DEPLOYED CONFIGURATION.
Now everything should be deployed to the target server and be registered in both the configuration database and the global assembly cache as shown in Figure 2.

Figure 2: Our Deployed Solution
4. Our final step is to “enlist” and “start” our send ports and send port groups and wait for the magic to happen!
Not too bad considering the fact that the BTS2004 documentation has over 125 pages covering “deployment”. If you're like me, this section of the help file was one of the most daunting to understand. Any set of instructions that requires a flow-chart like this is way too complicated. Trust me! It's really not too bad if you keep things simple.
Posted
08-10-2004 4:49 PM
by
Jeff Lynch