BizTalk Server 2013和部署MSI与动态发送端口 [英] BizTalk Server 2013 and deployment MSI with dynamic send ports

问题描述

Hello社区，想知道是否有任何帮助这个奇怪的问题。

部署应用程序msi失败进入BizTalk 2013 prod环境，在部署包含所有业务流程的项目dll时失败，
并报告未能应用早期绑定。  此项目中唯一的早期绑定是动态发送端口。  我无法在我的QAS环境中重新创建问题，在该环境中，相同msi的部署工作正常。  

• 我可以建立一个除了动态创建的msi之外没有任何绑定的msi，这也会在导入时显示相同的行为。  
• 我测试部署了第二个不相关的应用程序，该应用程序也使用动态发送端口，这显示了问题。  
• 将程序集直接添加到BizTalk控制台会显示相同的行为。
• 没有动态发送端口的msi应用程序的部署是可以的。

动态ports使用一个包含自定义管道组件的管道，我可以确认它在正确的目录中可用

• C：\Program文件（x86）\Microsoft的BizTalk Server 2013\Pipeline部件

错误中没有具体的详细信息，除了。

导入向导[09/05/2014 08:20:47]：导入应用程序时出错

导入向导[09/05/2014 08:20:47]：某些资源的变更请求失败。

<强> BizTalkAssemblyResourceManager未能完成端型改变请求

<跨度风格= "字体大小：7PT; font-family：Verdana，sans-serif"> 无法部署早期绑定。

无法更新绑定信息。

< span style ="font-size：7pt; font-family：Verdana，sans-serif"> 应用程序出错。

 

其他可能相关的信息：

• QAS和PROD之间的主要区别在于PROD是一个双节点集群。如果在任一节点上尝试，导入行为都是相同的。 当前在两个节点中都安装了程序集。
• 动态端口设置在非群集主机的处理程序上（均为适配器类型SMTP）。
• 我已确保所有适配器处理程序在两种环境中都设置相同。
• 项目文件从BizTalk 2010迁移到BizTalk 2013，导入然后使用VS 2012转换。
• msi按照惯例安装了程序集，它们确实存在于.net 4 gac
• 在不同的应用程序中有一个共享资源的引用，这个应用程序安装和导入确定。

我现在有点陷入困境，我可以选择在业务流程中从头开始重新创建动态端口并重新部署到开发人员希望VS2012在转换项目时没有太优雅地处理
。我可以将    一个帮手类而忘记使用动态发送，而不是沿着那条路走下去。我仍然怀疑这是QAS和PROD之间组的设置
的小差异但是我看不到任何跳出来的东西。

欢迎任何评论。

解决方案

听起来好像无法识别所需的资源。您提到在动态端口中使用自定义管道 - 如果您只是尝试查看此问题是否可以重现使用PassThru管道？

通常值得检查Windows事件日志，看看是否还有其他错误，这些错误详细说明了它究竟会被卡住的更多信息。

Hello community, wonder if any help out there for this odd problem.

Deployment of application msi fails into BizTalk 2013 prod environment, fails when deploying the project dll that contains all the orchestrations, and reports a failure to apply early bindings.  The only early bindings in this project are dynamic send ports.  I cannot recreate the problem in in my QAS environment where deployments of the same msi works fine.  

• I can build an msi without any bindings at all except for the dynamically created ones, and this also display the same behaviour on import.  
• I have test deployed a 2nd unrelated app that also uses dynamic send ports, and this displays the problem.  
• Adding the assembly directly to BizTalk console displays the same behaviour.
• Deployment of msi apps without dynamic send ports are ok.

The dynamic ports use a pipeline including a custom pipeline component which I can confirm is available in the correct directory

• C:\Program Files (x86)\Microsoft BizTalk Server 2013\Pipeline Components

No specific further detail is available in the error except.

Import Wizard[09/05/2014 08:20:47]: Error in Importing Application

Import Wizard[09/05/2014 08:20:47]: Change requests failed for some resources.

BizTalkAssemblyResourceManager failed to complete end type change request.

Unable to deploy early bindings.

Failed to update binding information.

Error in the application.

 

Other information that may be relevant:

• The main difference between QAS and PROD is that PROD is a two node cluster.  Import behaviour is the same if attempted on either node.  Assemblies are installed in both nodes currently.
• The dynamic ports are set on handlers that are non-clustered hosts (all are for adapter type SMTP).
• I have ensured that all the adapter handlers are identically setup in both environments.
• The project files were migrated to BizTalk 2013 from BizTalk 2010, imported and then converted using VS 2012.
• The msi has installed the assemblies as per usual and they do exist in the .net 4 gac
• There is a reference to a shared resource in a different application, this application is installed and imported ok.

I’m a bit stuck at what to try now, I have option where I could recreate the dynamic ports from scratch in the orchestrations and redeploy to dev in the hope it’s something that VS2012 didn’t handle too gracefully when converting the project.  I could move the functionality into a helper class and forget about using dynamic sends, rather not go down that route.  I'm still suspecting this is small difference in setup of the group between QAS and PROD but I can't see anything jumping out.

Any comments are most welcome.

解决方案

It does sound like it cannot identify the resources it needs.  You mention that you use a custom pipeline in your dynamic ports - have you tried to see if this issue is reproduceable if you just use a PassThru pipeline?

It is often worth checking the Windows Event Log to see if there are any further errors that detail more information on what exactly it's getting stuck on.

这篇关于BizTalk Server 2013和部署MSI与动态发送端口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！