Here is an issue with the BizTalk mapper that resulted in a little hair loss recently.
I was working on a fairly complex BizTalk map that was using scripting functiods to reference functions in an pre-existing .NET assembly.
In a couple of instances, the code in the Helper assembly wasn't quite what needed, so I switched from using the Helper Class function to using inline C#.
Once I changed the functiod to use inline C#, the Configure Functiod Script dialog looked like the screen-shot below.
As you can see, even though the Script type is Inline C#, the configuration for the External Script is still their. This is very important.
For most of the "one-off" functions, I needed more parameters than what was need by the original .NET assembly functions.
So I wired up all of my links, click Build and ended up with the following error.
The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.
Note: X and Y are place holders for the actual number of parameters.
Ok. I've seen this message plenty of time before. I click through each of the scripting functoids in the error list. However, all of them had the right number of parameters.
I clicked build again.
The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.
Ok. Visual Studio must be acting up, so I cycled the entire machine to make sure an potential cache issues are resolved.
Once the machine booted and I got Visual Studio restarted, I tried to build the project again.
The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.
Now I'm mad. I know that the functiods have the right number of parameters. Cycling the box should have fixed any weird "out of synch" errors.
So I start tried a little bit of everything. I disconnect and reconnect links. Nothing. I change the order of the parameters. Nothing.
Finally, I reset the inline script buffer and re-pasted the code... and that function disappeared from the error list.
Hmmm, so what's the difference
| Pre-Reset | Post Reset |
|  |
Resetting the Functoid cleared the External Assembly Configuration.
With this new information in hand, I open the map up a raw XML to take a look at the guts of the situation. This is what I found:
Originally, all of my scripting functoids used methods from the External Assembly. When I decided to use, Inline C#, I modified the existing functiod. Instead of removing the reference to the External assembly function, the functoid added the inline function to the already defined Scripter Code block. Because my inline function required a different number of parameter than the function from the external assembly, I was getting an input parameter count error.
That brings me to the moral of the story, anytime you are changing the way a scripting functoid is being used, hit the "reset" key. It will save you a world of pain.