Service xlang/s引擎事件日志条目：创建X服务时失败。类型为'的对象；Y'；无法转换为类型'；Y'；

xlang/s引擎事件日志条目：创建X服务时失败。“Y”类型的对象无法转换为“Y”类型

此事件日志条目似乎与此处讨论的内容相同：

我已经调查了这篇文章中提供的两种解决方案，但都没有解决我的问题

我正在运行BizTalk 2010，并通过一个统一的顺序车队看到了这个问题。业务流程的每个实例最初都按预期激活。第二个接收形状之前的所有形状执行时都不会出现问题。当业务流程实例收到第二条消息时，就会出现问题。执行不会超出与第二条消息对应的接收形状

使用grouphub页面，我可以看到第二条消息与正确的服务实例相关联。此服务实例已挂起，上面显示的错误消息将显示在事件日志中

偶尔（大约每5次中有1次），上述问题不会发生。也就是说，后续消息由业务流程处理。我每次都输入相同的测试文件。更有趣的是，如果我在第二个接收形状之前的侦听形状上设置了断点（在Orchestration Debugger中），则问题永远不会发生

我在使用调试器时没有发现问题，这让我怀疑这是否是一个时间问题。不幸的是，我似乎无法控制时间

有人知道如何防止这个问题发生吗

---

谢谢

是否只涉及一台BizTalk主机服务器？如果问题与从GAC加载所需程序集的困难有关，我不会感到惊讶。如果涉及多个BizTalk服务器，则可能是其中一个是罪魁祸首（或者只有一个不是罪魁祸首）。当然，这可能没那么容易

另一种选择是关于您链接到的另一个问题的第二个答案，说明检查所需的模式是否不止部署一次。我以前也遇到过这个问题，要想知道这是怎么回事，唯一的办法是在BizTalk管理控制台中的

BizTalk Group>Applications>>架构下查看
，然后按目标名称空间排序，查看是否有任何两行（或更多行）具有相同的目标名称空间和根名称组合

该问题也可能是由模式不匹配引起的，其中可能部署了比预期更旧/不同版本的模式，而仅有时存在的字段（因此它有时工作）会导致不匹配

当然，这些只是理论，无法查看您的环境并查看实际的BizTalk工件。
我向Microsoft提交了此问题。事实证明，“该行为实际上是XLANG编译器依赖类型包装器的方式存在的设计限制。”这个问题是由一个非常特定的场景引起的。我们有一个编排，其中一个消息变量直接引用模式，另一个消息变量引用基于同一模式的多部分消息类型。编排、模式和多部分消息类型都在不同的项目中定义

Microsoft建议我们修改其中一个变量，以便两者都引用架构或MMT。不幸的是，保持变量不变对我们来说至关重要。我们发现（并且微软证实）将MMT的定义与编排移到同一个项目中也解决了这个问题