BizTalk Project / Assembly Organization Gotcha

I have a real-world experience to share for organizing your BizTalk projects and assemblies. I think the natural tendency is to group “like things” together so if you have an orchestration with a schema or two and a custom pipeline you'd define all these artifacts in the same project. This way they're always kept together in source control, on disk and deployed together.

That same “benefit” is also the “gotcha” to watch out for. In my case, the custom pipeline is used to specify a schema formatted as a flat-file. The problem comes mostly during development and testing. If you update the orchestration you must stop, unenlist, undeploy, rebuild, deploy, bind, enlist, start - we've all done that hundreds of times. The problem is when undeploying the *assembly* containing the orchestration you're also undeploying the custom pipeline attached to the send port that's in the same assembly. BizTalk will then fallback to the standard Xml pipeline adapter on that port by default. Then, when you redeploy you're adding back the custom pipeline again which is where I get tripped up - I keep forgetting to switch the send port back to the custom pipeline.

The moral of this story is to use separate projects/assemblies for your custom pipelines and schemas. While this creates lots of little assemblies running around in your GAC, it can greatly reduce the failed tests because you forgot to rebind things!

Last note: Jon Flanders has more to say about pipeline components. Too bad this came out during the last phases of development for my current project - not enough time and too much to do!

Original post