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.
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: