| Jon Flanders 2006-01-13, 9:59 pm |
| 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 through
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.config
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).
>
|