Well we had the most awful time with this the other day. I posted this on the biztalk.general newsgroup but eventually solved the problem myself. Heres what happened.

We had two orchestrations published as webservices. (Using Biztalk 2004 on XP SP2) One was typed and the other untyped (ie) consuming an XmlDocument at the recievePort and assigning it to a specific message variable internally. The untyped one worked fine when called from another orchestration and from an NUnit test. The typed one however always threw a weird error message saying ” Server was unable to process request. –> File or assembly name FileName .dll, or one of its dependencies, was not found.” . We attempted the following

(a) I looked at the support article for the same at http://support.microsoft.com/?kbid=910295 but to no avail. I gave all possible users permissions on all temp folders, but the same message appeared.

(b) Both webservices had anonymous access enabled and i set the ASPNET and Isolated Host users to have permissions to the temp folders and the databases. (I even temporarily let the ASPNET user run as SYSTEM :-)).

(c) I tried adding some code to the asmx.cs to write custom statements to the event log but that didnt work either. It seemed that the web service was just not being called.

(d) found an article which said that Proxy projects that have names more than 61 characters long cannot be compiled (weird huh). But even shortening the names to well below 61 didnt help.

(e) enabled detailed error tracing but this was of no use since the webservice was not being JIT compiled correctly (thats the reason for the weird error message)

Finally we had a breakthrough. We first changed the input operation to accept an untyped message. The system appeared to run for a longer time but returned the same error. While looking at the custom logging files we had setup (using EntLib) it appeared that the orchestration was indeed being invoked by the webservice but the system still threw the exception. Looking at the stack trace we found something about a method which has the word ‘response’ in the name. At that time this didnt ring any bells, but in desperation we changed the return type to XmlDocument and the wretched thing started working!!

It could have just been the response message wasnt being constructed correctly, but all we do now is construct a typed response message and then assign it to an XmlDocument and send it to the response port.

I cant understand it. Typed messages are the bread and butter of Biztalk and untyped messages are not frequently used. So for the system to complain about a typed message is very strange indeed. Anyway, this is a tidbit i thought i’d share in case someone else comes across this problem anytime. Im hoping to find some time later to try and reproduce the problem and do some more detailed debugging. Its a pity that orchestrations are so difficult to debug (even with the orchestration debugger).

Speaking at a user group: I’ve been invited to do an Introduction to Biztalk at the .NET Exchange User Group in London next week. The speaker who was supposed to do this dropped out and as i had volunteered earlier to share my experience with BTS, I’ve been asked to do the honors. Gotta get the old slides polished up and get a demo working.