Question : Building VC++ COM server to work with VB

I have an EXE server for ATL COM ActiveX controls. It works fine with the activex test container. When I try to add my COM component to a VB standard exe project, VB informs me that it failed to load my EXE server program.

Answer : Building VC++ COM server to work with VB

This is a repost of an email to eetay...

Well, very interesting…

I have to admit here, although I have quite a bit of experience using ATL, I have much less experience in implementing ATL controls.  

I also saw the same problem you saw. So, I tried all the usual debugging techniques on your project first.  None of which exposed a problem.  So, I went to my texts to read up on ATL controls.  Here is what I found, which very probably explains the problems you are having…

In the book, “Beginning ATL 3 COM Programming”, by Richard Grimes, on page 425,
   “Because controls have windows it means that they must be run in an STA.  This also means that they must be housed in a DLL.”

This makes sense to me.  VB can’t load your control because your control is out-of-proc (it’s in an EXE).  Technically, your control is a valid COM object.  In fact, I created a new C++ project and added code to create an instance of your interface, and it worked just fine.  But, I did not create it as a control.  It had no window of its own.  So, that’s why a solution wasn’t presented by my debugging.  See what I’m saying?

Here is how I would tackle this.   First, I assume that you are writing this control in order to expose a GUI interface to some sort of business logic layer, right?  In other words, you want to have one chunk of code which does actual work, and another chunk of code which will present a GUI layer on top of the worker code.  Well, in that case, and seeing as how you said that you want to have a central server expose the buisness logic, I would suggest a rearchitecture of your project.  First, create an ATL COM EXE server in C++ which contains the interfaces that do the real work.  This is the buisness logic layer.  Then create another, completely separate project (in either C++ or VB), this time an ATL COM DLL server, in which you implement the control you tried to implement before.  This time, the DLL will actually be a client of the EXE.  Personally, I think this architecture model makes more sense than putting all the code in one module.  I always say that the GUI is a client of the server.  I think that you will find that in the future when you need to maintain & extend this code (no code is ever finished), you won’t be hamstrung in the buisness logic by the constraints placed on the control logic.  Also, future developers will be able to more easily make sense of the layering you build in to your code using this technique.

Hope this help somewhat.  Any questions, please post.