2

I'm trying to deploy a new version of a BizTalk application that contains common orchestrations for several applications (about 20 or so). The new version contains a new orchestration that will be used by several new applications.

When I try importing the msi for the new version I get an error saying:

"Cannot update assembly "[assembly_name]" because it is used by assemblies which are not in the set of assemblies to update. To update the assembly, remove the following assemblies: "[dependant_assembly1] [dependant_assembly2] ..."

The BizTalk server is not accessible from a development environment so the application must be updated using the BizTalk administration console. How do I import the updated application without having the remove and reinstall all 20 or so dependant applications?

Thanks

SteveC
  • 15,808
  • 23
  • 102
  • 173
Eric v
  • 21
  • 1
  • 2
  • This is not the total answer, but this post has helped me in the past to determine when I need to redeploy or re'GAC. You can figure this into your overall strategy: http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,628aecb9-4eaa-4044-88c9-92cb53f81bdf.aspx – Christian Loris Sep 13 '10 at 12:59

2 Answers2

4

It sounds like you are deploying a new base application with the same version numbers as an existing, older version.

What works for us:

  • Every time you deploy a new version of your application, increment the version number (since the assemblies are GAC'ed, BTS supports side by side versioning). Any custom assemblies which are changed should also be versioned.
  • After deploying to your new Application to your local BizTalk, edit the resources to ensure that the correct (latest) versions of all referenced assemblies and bindings etc are up to date (remove old ones, add new ones).
    • Your common application will now contain both old and new versions of the assemblies. Newer versions of your 'client' applications will use the later version of your base / framework / common application.
    • Once all dependent applications have been upgraded, you can then remove the old version.

But the real solution seems to be to consider decoupling your applications more, e.g. by using messaging between the applications - this way, you can split out just the schemas as a common reference to the applications.

StuartLC
  • 104,537
  • 17
  • 209
  • 285
1

You can actually hack the deployment process on BT a little bit further than this, if you want to omit the versioning, depending on your access to the actual BT box. (Convince your sysadmin)

If you only have access to the deployment console, stop your dependent applications, remove their reference to the application you want to upgrade, and then deploy over the top, re-add your references and restart the dependent applications. You don't actually have to reinstall.This method is tedious and sucks but it will work. We do this because we have too much in our BT installs to further clutter them with multiple versions of the same app

Here is the hack. You'll need either access to the server (which I know you said you don't have) or the ability to install a service which can receive a dll and preform the below function for you. (I'm thinking you might convince someone to let you set this up) DISCLAIMER, this is not a supported solution and I claim no responsibilty blah blah blah

We do this all the time as we have WAY too many applications to do the first solution. You can slam your newly compiled DLL into the GAC. This NOT recommended by MSFT etc. but we use it in production on servers that have approx. 4000 dlls in the GAC and 1200 BT applications. You'll need to make sure that your metadata is identical i.e. you have the same version, key token etc. and you'll want to have some way of tracking your dlls outside the versioning system (we build a custom deployment infrastructure to do this). Finally once you have pushed your dlls into the GAC you'll need to restart your biztalk services. Make sure you don't have any suspended instances referencing the app you want to redeploy because they will prevent biztalk from pulling a new reference from the GAC when it restarts.

Finally it is important to note that this method will NOT work if your changes require changes in the MessageBox subscrition (things like changes in receive shape filters, correlations etc.) You will also be giving up some functionality in the orchestration debugger if you use this method to change the structure of orchs. The graphic will display the structure of the orchestration when last properly installed but your event list will be correct for the newest version. Finally, if you are replacing schema dlls you want to make doubly sure that you restart services as BT will cache schemas indefinitely.

kirps
  • 1,345
  • 2
  • 17
  • 28