Actually this happens when a pipeline throws a certain class of exceptions
in the ASP.NET worker process.

The Pipeline executes in the Default Domain because it is being called throu
gh
COM interop - the SOAP Adapter runs in a particular named AppDomain (based
on the Application setting).

The .NET-COM interop tries to marshal the exception accross an AppDomain
boundry - and because the assembly isn't loaded in the Default Domain - this
exception happens.  The only two fixes are (both are bad really) - put the
Default pipeline assembly into the GAC or add a codebase hint to machine.con
fig
or web.config.


Jon Flanders [MVP]
http://www.masteringbiztalk.com
http://www.quicklearn.com/workflow.htm

> Hi Tommy,
> 
> OK, here's an idea:
>
> I'd check to see that the user you're running your isolated host (i.e.
> the
> user you're using to run the AppPool you're using for your BizTalk
> webservice) has access to the
> C:\Program Files\Microsoft BizTalk Server 2004\Pipeline Components
> folder. Maybe that's the problem.
> Other than that, I can only stress again that you should try the
> fusion log viewer tool (and remember to configure it to log ASP.NET
> and errors).
>

[ Post a follow-up to this message ]