Over the past few years, a lot of my work has been centered around Microsoft BizTalk Server. While I have a lot of good things to say about the product, there are a few things that really get under my skin. I had very high hopes that they would be addressed in BTS 2006, but it seems that there are some things the BizTalk team just isn’t ready and/or willing to address.
If I’m way out of line on any of these, please let me know. I would love nothing more than to be shown how to address these issues.
Building BizTalk Projects
Unless I have just really missed the boat on something, integrating BizTalk projects into any kind of automated build process is really a nightmare. When Visual Studio 2005 came out, it really looked like Microsoft was “getting it.” With the .NET Framework SDK installed on a machine, you could build your projects without Visual Studio or any other software installed. Project files are now just build scripts in disguise. Project files, that is, other than the ones for BizTalk projects. For some inexplicable reason, BizTalk projects are still in the same old Visual Studio 2003 format. This exempts BizTalk projects from things that are generally considered good development practices, like continuous integration builds.
Some of you (if there are any of you at all) will argue that there are workarounds and custom build actions that enable the building of BizTalk projects. This is accomplished by subverting the normal build process and shelling out to Visual Studio. There are at least a couple of problems with this. First, it means a Visual Studio/BizTalk installation on the build server. Not only does this mean licensing costs, it also feels a lot less clean. By ending around the “normal” build tool, I would imagine that logging and transparency are comprimised.
Another side effect of this is that developers without BizTalk installed can’t build the projects. Restricting their ability to edit the projects is one thing, but keeping them from building the project prevents them from determining if a code change will break the build when checked in.
Everything in the GAC
The GAC can be a very powerful tool. It can also cramp a developer’s style like nobody’s business. I can’t tell you how may times I’ve made a change to a component consumed by BizTalk only to wonder why I wasn’t seeing a change in the behavior. Is there not any other way that this could be approached? The workarounds for GACing your assemblies are almost as cumbersome. I’ve used the registry key for assembly resolution. I’ve tried editing the BTS AppDomain creation information to use a different base path. Nothing seems to stop the interruption to my normal development flow.
Another consequence of this is that providing configuration information to your BizTalk artifacts is hampered. Editing the BizTalk service configuration seems risky and, once again, just makes BizTalk development seem different than anything else you encounter in the .NET world.
Poor Facilities for Unit Testing
Has anyone actually come up with a workable solution to BizTalk unit testing? There are a few tools provided to execute pipelines, etc., but they don’t really integrate well with the MS Test framework. Testing an orchestration without jumping through the deployment and binding hoops is next to impossible. I was extremely excited when I heard about BizUnit. That lasted until I realized that the tool was not correctly named. BizUnit performs what I would consider acceptance or integration tests, but does not allow you to test BTS artifacts in isolation. Last time I checked, a unit test meant testing a unit of code and as little as possible of anything else.