1

I am trying to create a custom CodeActivity to use with TFS 2010. Most of my work thus far has been based on this series (call out of thanks to Ewald for this).

Everything was running great until I tied in the second piece. I am attempting to do some BizTalk configuration using the Microsoft.BizTalk.ExplorerOM.dll. One of the gripes about the dll is that it is x86 only, and an internal dll from Microsoft that I have no control over. I had done the same tasks before in VS2008, and I am basically just trying to move that same functionality over to VS2010, clean it up, and integrate it into work flow.

When I first added code from ExplorerOM I got the following error:

Explorer OM is not supported in a 64bit process.

After changing the supporting projects over to 32 bit, I am getting the following:

Cannot create unknown type '{clr-namespace:BizTalk.Deployment.CodeActivities;assembly=BizTalk.Deployment.CodeActivities}UndeployBizTalkBindings'.

After some research on the web I am fairly certain this is due to the 64 bit build process being unable to load my, now 32 bit, dll.

Is there a way to specify the build process itself to be 32 bit? I did not see any settings in TFS. I have considered running the code through a simple 32 bit console app and using the InvokeProcess activity, but my fear is that without access to the context object I won't be able to have the granularity of logging I was hoping to achieve. The work will be fairly involved.

Any thoughts on how to accomplish this? I would be open to other solutions as well.

Andrew Dunaway
  • 1,206
  • 3
  • 16
  • 29

2 Answers2

0

What about hosting a WCF service within a Windows service? If you implement sessions within the service, you should be able to maintain context.

Rich
  • 2,076
  • 1
  • 15
  • 16
0

So it turns out the best way to accomplish this was through the InvokeProcess activity. I was able to write a small command line utility and invoke it using this. The standard output can be wired to the tfs system through the InvokeProcess activity itself, keeping logging and information centralized.

Theoretically this pattern could be easily repeated with a small command line wrapper for any scenario that requires a call to a 32-bit process.

Andrew Dunaway
  • 1,206
  • 3
  • 16
  • 29