重新部署其他应用程序使用的 BizTalk 应用程序
我正在尝试部署新版本的 BizTalk 应用程序，其中包含多个应用程序（大约 20 个左右）的通用编排。新版本包含一个新的编排，将由多个新应用程序使用。
当我尝试导入新版本的 msi 时，出现错误：
“无法更新程序集“[程序集名称]”，因为它由不在要更新的程序集集中的程序集使用。 要更新程序集，请删除以下程序集：“[dependant_ assembly1] [依赖程序集2] ...”
无法从开发环境访问 BizTalk 服务器，因此必须使用 BizTalk 管理控制台更新应用程序。如何导入更新的应用程序，而无需删除并重新安装所有 20 个左右的依赖应用程序？
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来您正在部署一个新的基础应用程序，其版本号与现有的旧版本相同。
对我们有用的方法：
但真正的解决方案似乎是考虑更多地解耦应用程序，例如通过在应用程序之间使用消息传递 - 这样，您可以仅将模式拆分为对应用程序的公共引用。
It sounds like you are deploying a new base application with the same version numbers as an existing, older version.
What works for us:
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.
如果您想省略版本控制，您实际上可以比这更进一步地破解 BT 上的部署过程，具体取决于您对实际 BT 盒子的访问。 （说服您的系统管理员）
如果您只能访问部署控制台，请停止依赖应用程序，删除它们对要升级的应用程序的引用，然后在顶部进行部署，重新添加引用并重新启动依赖应用程序。你实际上不必重新安装。这个方法很乏味而且很糟糕，但它会起作用。我们这样做是因为我们的 BT 安装太多，无法用同一应用程序的多个版本进一步混乱
这里是黑客。您需要访问服务器（我知道您说过您没有）或能够安装可以接收 dll 并为您执行以下功能的服务。 （我想你可能会说服某人让你设置这个）免责声明，这不是一个受支持的解决方案，我不承担任何责任等等等等
我们一直这样做，因为我们有太多的应用程序来执行第一个解决方案。您可以将新编译的 DLL 放入 GAC 中。 MSFT 等不推荐这样做，但我们在生产中使用它的服务器大约有。 GAC 中有 4000 个 dll，BT 应用程序有 1200 个。您需要确保您的元数据是相同的，即您具有相同的版本、密钥令牌等，并且您需要有某种方法在版本控制系统之外跟踪您的 dll（我们构建了一个自定义部署基础架构来执行此操作） ）。最后，一旦您将 dll 推送到 GAC 中，您将需要重新启动 biztalk 服务。确保没有任何挂起的实例引用要重新部署的应用程序，因为它们会阻止 biztalk 在重新启动时从 GAC 中提取新引用。
最后需要注意的是，如果您的更改需要在 MessageBox 订阅中进行更改（例如接收形状过滤器、相关性等的更改），则此方法将不起作用。如果您使用此方法，您还将放弃编排调试器中的一些功能改变兰花结构的方法。该图形将显示上次正确安装时的编排结构，但您的事件列表对于最新版本来说将是正确的。最后，如果您要替换架构 dll，您需要双重确保重新启动服务，因为 BT 将无限期地缓存架构。
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.