views:

129

answers:

1

The .NET application for which I'm responsible uses a third-party control that is only available as a 32 bit COM component. I've been banging my head against walls for a while trying to find a way to allow the component and the app to work together in 64-bit mode. We got some help from the control vendor - they don't plan on supplying a 64 bit version of the component anytime soon, but they attached a C# solution that uses the WebBrowser control to load the component and a C++ solution that uses some fun OLE code to dig a reference to the control's interface out of the WebBrowser.

The good news is that the code does what it's supposed to do; the component loads correctly inside of a 64 bit solution, and I'm dredging up my old, spotty knowledge of ATL to work my way through the C++ solution to figure out how to retrieve the control interface into our C#.

My concern is that I don't understand this configuration nearly well enough to determine what problems I might be exposing our app to. Has anyone done anything of this nature? My main worry is that we might start seeing mysterious crashes which I'll eventually trace back to a value being mangled by the 32 bit control, and I'll be right back where I started.

The control, for reference, is Solidworks' EModelViewControl, which is included in the EDrawings lightweight CAD viewer. It's not a particularly complex control, although their automation setup is a little bit interesting.

+3  A: 

You should be able to wrap your 32-bit COM component with an out-of-process COM server that you can talk to from your 64-bit application.

These related topics have some more details and references:

64 bit C# with a 32 bit VB6 COM object

Access x86 COM from x64 .NET

0xA3
Thanks! I'm not sure why I couldn't find those using the search, but they're quite helpful.
Mike Burton