Do work arounds to avoid 'unconstructed message' compiler errors violate BizTalk message immutability rule?

Question

I've been working with BizTalk a while now, and one of the core rules is that messages are immutable - ie once they have been created they cannot be changed. Which makes a lot of sense.

In BizTalk orchestrations, when using scope blocks one of the common scenarios that you can encounter is the 'use of un-constructed message' compiler error where a message is being used within the scope block that is not 100% determined to initialised within scope. A common work around is to to have an assignment shape outside the scope block that initialises the message in some way (either by some sort of 'dummy' map or an assignment shape that populates the message with a basic XMLDocument object etc.). The compiler is then happy.

But... Surely, this violates the rule? A message is given a value outside scope, and then further down in the scope block, it can be given another via a map or another operation.

Answer 1

No, not a all. :)

While a Message Instance is immutable, Variables can be (re)assigned at will just like any other .Net program.

So, what the compiler is actually complaining about is a possibly unassigned variable. It's just that the XLang compiler sees unassigned Message variables as particularly bad.