是否有解决方法来避免 'unconstructed message' 编译器错误违反 BizTalk 消息不变性规则？
Do work arounds to avoid 'unconstructed message' compiler errors violate BizTalk message immutability rule?
我使用 BizTalk 已经有一段时间了，核心规则之一是消息是不可变的 - 即一旦创建它们就不能更改。这很有道理。
在 BizTalk 业务流程中，当使用范围块时，您可能遇到的一种常见情况是 'use of un-constructed message' 编译器错误，其中在范围块内使用的消息未 100% 确定在其中初始化范围。一个常见的解决方法是在范围块之外设置一个分配形状，以某种方式初始化消息（通过某种 'dummy' 映射或使用基本 XMLDocument 对象填充消息的分配形状等） .然后编译器很高兴。
但是……这肯定违反规定了吧？一条消息在范围外被赋予一个值，然后在范围块中进一步向下，它可以通过映射或其他操作被赋予另一个值。
不，不是全部。 :)
虽然消息实例是不可变的，但可以像任何其他 .Net 程序一样随意（重新）分配变量。
所以，编译器实际上抱怨的是一个可能未分配的变量。只是 XLang 编译器认为未分配的 Message 变量特别糟糕。
我使用 BizTalk 已经有一段时间了，核心规则之一是消息是不可变的 - 即一旦创建它们就不能更改。这很有道理。
在 BizTalk 业务流程中，当使用范围块时，您可能遇到的一种常见情况是 'use of un-constructed message' 编译器错误，其中在范围块内使用的消息未 100% 确定在其中初始化范围。一个常见的解决方法是在范围块之外设置一个分配形状，以某种方式初始化消息（通过某种 'dummy' 映射或使用基本 XMLDocument 对象填充消息的分配形状等） .然后编译器很高兴。
但是……这肯定违反规定了吧？一条消息在范围外被赋予一个值，然后在范围块中进一步向下，它可以通过映射或其他操作被赋予另一个值。
不，不是全部。 :)
虽然消息实例是不可变的，但可以像任何其他 .Net 程序一样随意（重新）分配变量。
所以，编译器实际上抱怨的是一个可能未分配的变量。只是 XLang 编译器认为未分配的 Message 变量特别糟糕。