I've been doing some Biztalk development lately, and for the most part, it's pretty straightforward. Granted, what I'm doing isn't all that complicated, so I know I'm not hitting some of the complexities of Biztalk - that, and I'm not responsible for the transformations that need to take place.

Given that, there are a few things that frustrate me about Biztalk, and I ran into one of them today. Of course, the only reason I ran into this was because I messed up in my initial planning. You see, we originally thought about putting all of our orcestrations into one DLL, but later decided it would be better to split them up by functionality. Each one of the different areas of functionality will use at least one shared schema. And that’s where I messed up. I put the shared schema into one of the Biztalk projects that was for a specific function.

Realizing this, we moved the schema to a new project that is specifically to hold shared information, such as this schema. This caused quite a few ripples throughout our project. First, the most obvious. The mapping needed to be updated to use the new schema. No problem. Then I had ports in and out for this message. Those had to be updated, but you couldn't update those until you deleted the connections from the port into the orchestration. Still, not a huge problem. And it makes sense. You can't change the schema something is using when it's being fed into something else expecting a different schema.

But then things got interesting. Since my receive port is exposed externally as a web service, I had to regenerate it. No problem (or so I thought). First, it took 3 times to get it to generate the service. This happened when I originally generated the service, so I pretty much expected that. But that's where things got strange.

After redeploying, I couldn't get messages to go through. It said there was no deserializer available. Then I looked at the generated code, and it wasn't pointing to the correct schema object. I changed that, regenerated my references to the web service (using WSCF of course!) and I was on my way.

But here's my question. Since these are just messages, and they had the same namespace, and they were the same message, why didn't it work? And second, but less important, why should it take 2 hours to move a file from one project to another? If it was plain ol' C#, then it would be a matter of minutes to move it.

And then there's the deployment process. I read a post by Scott Colestock about automating the deployment using Nant, and I'm definitely going to implement that. I'm still not sure what happened, but lots of stuff broke when I changed the Development and Deployment configs to Debug and Release, and it took a while to figure those out too. But it'll be worth it if I can automatically deploy my project, since Deployment is a pain. It just seems too easy to automate - I'm still not exactly sure why it wasn't automated out of the box. I hear it will be in BTS 2006, something I need to get my hands on when I can!