Update: I've been told now that the hotfix in KB979153 should correct this problem.
I’m posting this one problem I ran into this week so I don’t forget about it. The scenario was as follows:
We had an existing, working WCF service. Most of the operations in the service contract were not using explicit data contracts as input parameters; instead they were just using primitives (such as an operation taking a string as an argument), though data contracts were used for the response messages.
We were trying to consume this service from an orchestration in BizTalk Server 2009 RTM, so we added the reference using the WCF Service Consuming Wizard. This worked fine. All the schemas were correctly imported and new multi-part messages were defined for the input and output messages. Schemas were also created for the inputs and outputs.
The problem came when trying to actually populate the parameters of the input multi-part messages. In this case, this needs to be done by creating the input message with all the arguments using the right schema (which we had) and then assigning that message into the parameters part of the input multi-part message that would be actually sent to the send port.
The error was that the Orchestration Compiler (or Visual Studio) for that matter didn’t seem to recognize the parameters part in the message. Though it would pop up in Intellisense in an expression shape, any attempt to actually assign a value to it would cause an error about the assignment expression being invalid (because it doesn’t recognize the part).
I immediately went back to a BizTalk 2006 R2 installation and, sure enough, I was able to do this in minutes and have it working. So far, I had failed to find anything in the docs, the readme or on searches around the neck, but I was sure it had to be something relatively harmless. Well, just so I can find it easier next time:
The workaround is to import your WCF service metadata into a separate BizTalk 2009 project, then go and change the generated Port Types and Multi-Part Message Types so that they are have public visibility, and then add a reference to the new project from the one containing your orchestration. Then it will compile and work just fine.
Annoying little bug, isn’t it?
