Published on : Mar 21, 2011
Category : BizTalk Server
We are in the process of migrating some of our existing stuff from BizTalk 2006 to BizTalk 2010. As part of the process I was prototyping a web service call with some complex data models using WCF-basicHttp adapter.
I was consistently getting the following error message despite my various attempts like restarting host instances, redeploying the whole solution, uninstalling and installing assembly into GAC, etc
xlang/s engine event log entry: Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service
……
Exception type: TargetInvocationException
Source: mscorlib
Target Site: System.Object _InvokeMethodFast(System.IRuntimeMethodInfo, System.Object, System.Object[], System.SignatureStruct ByRef, System.Reflection.MethodAttributes, System.RuntimeType)
The following is a stack trace that identifies the location where the exception occured
……
Exception type: TypeInitializationException
Source: EA.BizTalk.Framework.WCF.Orchestrations
Target Site: Microsoft.XLANGs.BaseTypes.SchemaBase get_PartSchema()
The following is a stack trace that identifies the location where the exception occured
……
Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
……
Exception type: FileLoadException
Source: EA.BizTalk.Framework.WCF.Orchestrations
Target Site: Void .cctor()
Doing some research taken me to this article
http://support.microsoft.com/kb/2282372 where it explains about the error
Loading this assembly would produce a different grant set from other instances. Even though the KB article is not related to BizTalk issue directly, it just gave me the clue its something do with 64bit process and version of .NET framework.
I checked the settings of the default BizTalk host configuration and to my surprise its configured as 32 bit as shown in the below picture.
Surprisingly, when I tried to create a new BizTalk host, by default the “32-bit only” option is checked by default.
Solution:
So, the solution is to create a new 64 bit host (simply, uncheck the 32bit only option) and create required host instances, then configure your orchestration to run inside the newly created 64 bit host as shown below.
Once the orchestration issue is sorted, you’ll experience something similar on the WCF-basicHttp adapter send port as shown in the below figure.
There was a failure executing the response(receive) pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Send Port: “WcfSendPort_CustomerService_BasicHttpBinding_ICustomerService” URI: “http://localhost:7684/CustomerService.svc” Reason: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
The solution to the problem is same, this time you need to create new Send handlers for the WCF adapter you are using and reconfigure your send port to use the new send handler as shown in below pictures