Same resource/orchestration across different BizTalk Applications in the same BizTalk Group

Question

I have researched this through different mediums, whether it be Google, Bing, published books, and so on, and find it hard to believe that although this issue has been asked several times, there's no way to address it.

I tried searching for this in stackoverflow but was not able to find anything matching my search parameters. So if there is one, please point me over there. Thanks!

Here's the question:

I need to create several Biztalk applications in the Biztalk Admin Console -- one application will be for DEV and points to the DEV SQL server, another will be for QA and points to the QA SQL server, and so on. Each application needs to have its own container for the resources that all other applications have.

Example: Application #1 has ReadFoo.dll, version 1.0.0.0; WriteFoo.dll, version 1.0.0.1

I'd like to create a second application, which will point to a completely different SQL Database instance, that has its own ReadFoo.dll, version 1.0.0.1; WriteFoo.dll, version 2.0.0.0.

Biztalk complains that the same resource already exists elsewhere in another application when I try to do a 2nd application.

Googling for this leads me to suspect that I'd have to create a second BizTalk Group, with different BizTalk configuration database on a different server, in order to pull this off.

Any suggestions?

Answer 1

It's considered a best practice to use separate development and staging environments. Applications were introduced in Biztalk 2006 to simplify the administrative tasks of deploying and modifying related Biztalk artifacts. While the name of this concept might imply that you can duplicate the same resource in multiple applications, this is not the case. All Biztalk assemblies need to be strongly named and added to the global assembly cache, hence they need to be unique on a single machine (Biztalk host instance).

You can try to circumvent this by manually manipulating assembly version numbers, but I think that approach is a PITA to maintain. Misconfiguration can lead to calling the wrong assembly for example. It's a lot easier to export your application as an MSI file and to import it on the desired environment.