At some point in your career you’re going to face troubles. If you’re lucky, or good, they’re someone else’s fault. There isn’t much you can do about poor choices by other programmers or your management. There are some things you can do to minimize the ones you make though.
One pain point is deployments of new code. It’s expected that it will be smooth and trouble free. If there are thousands of details to get correct it’s a big ask.
One trivially simple change you can make is to reduce dependencies. One less thing to go wrong is always a good thing. So what’s the trivial change?
Almost every demo and example you see in BizTalk tutorials is organized the same way. It’s programmer mindset, and it’s the least reliable way. They put all the schemas in one assembly, all the pipelines in another, the maps in another, and the orchestrations in yet another. It makes sense to organize them by function right? Except… In order to make sure the code you wrote and tested resides in four files. If they aren’t deployed together (and the host instances restarted to flush the cache) you get that dreaded phone call.
There’s no technical reason why they have to be separated. The code is slower to execute and more fragile. The answer is simple and doesn’t cost you a thing. All your code should be in one assembly. Your code can’t fail because not all of it was deployed.
There are exceptions of course. Any helper code you might have created can’t go in the same assembly. I’ve tried and couldn’t make it work. It should, but it doesn’t. If you know why, or have managed this feat please let me know?
p.s. Don’t forget to add folders to your visual studio project. You can organize your code neatly and still have it in the same assembly.
Have a great day.
Non maskable interrupt 