Nick Heppleston’s BizTalk Blog

Imagine a scenario where you want to create 1400 receive locations; to make life simpler, you’d probably want to use WMI or the BizTalk Explorer OM.

Not much of an issue there, however what happens when you try an run some custom C# code that creates the receive locations (and therefore references the Microsoft.BizTalk.ExplorerOM assembly) from within an orchestration [expression shape] that executes as a 64-bit process?

You get the following error XLANG/S error:

Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 10034
Date: 14/08/2007
Time: 19:22:49
User: N/A
Computer: WINBT01
Description:
Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘Demo.Integration.CustomerLink.Orchestrations.UserAdministration(108ace24-3b9d-e084-c9ea-f342878676e6)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 95ae9c6b-9af4-468b-9a3c-6398d7fba629
Shape name: CreateFileReceiveLocationExpression
ShapeId: 3695bc5d-cec3-4c9b-b2ca-84e0917a7bc1
Exception thrown from: segment 1, progress 22
Inner exception: Explorer OM is not supported in a 64bit process.

Exception type: BtsException
Source: Microsoft.BizTalk.ExplorerOM
Target Site: Void .ctor()
The following is a stack trace that identifies the location where the exception occured

at Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer..ctor()
at Demo.Integration.CustomerLink.FileReceiveLocation.Create(String user)
at Demo.Integration.CustomerLink.Orchestrations.UserAdministration.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

Hmmm, that’s a bit odd, especially given that both the custom and Explorer OM assemblies are compiled to MSIL (not a target platform), which should suggest that when invoked from the 64-bit orchestration the JIT-Compiler will compile both to run a 64-bit process:

This doesn’t appear to be the case at all - in order to successfully run, you need to force the Host under which the orchestration is executing to run in a 32-bit process (rather than the native 64-bit) using the ‘32-bit only’ checkbox on the Host Properties page:

This doesn’t make much sense to me, so I plan on doing more investigation into the problem. I’ll post my findings once I have a definitive answer.