COM proxy stub dll and why do you need it

Let’s start from the end, after all ordering of posts on a blog make it natural. Please, notice that this post is rather for people starting writing COM, veterans would find it pretty evident. On another hand, remembering all the small details may be bothersome, so I decided to push it to the blog as a reminder.

 

Suppose you implemented your COM object, everything look fine while you test it in DLL or in the same exe file, and now you are trying to host it in EXE or use a threading model different from apartment. The behavior becomes a little puzzling. To start from, your test driver returns 0x80040155 (REGDB_E_IIDNOTREG). What happens?

 

You investigate more, and notice that your class factory CreateInstance method is called all right, it goes through creation, it calls QueryInterface, which also works just, fine, and it returns S_OK, but that’s not what you test driver that called CreateInstance gets!

 

Apparently, COM runtime got in the middle, tried something, failed, and returned failure instead of S_OK. Why? You investigate more and notice that Query Interface on your object created by CreateInstance is called several times with some strange IIDs:

 

{00000003-0000-0000-C000-000000000046}

{0000001B-0000-0000-C000-000000000046}

{00000018-0000-0000-C000-000000000046}

{00000019-0000-0000-C000-000000000046}

{4C1E39E1-E3E3-4296-AA86-EC938D896E92}

You check a few of them up and find out that these are marshalling interfaces. But, you wonder, should the default marshaler handle it, if you did not implement them?

 

Yes, it will. But it needs the description of your interfaces. So, either description of interfaces of the proxy stubs should be available. There are two ways to do that: type library (which has a few restrictions) or proxy stub DLL. I will talk about type libraries some other time, for now let’s see what traps expect you when creating a proxy stub.

 

First, what do you need for you proxy stub? Surprisingly little – just your IDL file. If you do it in Visual Studio, create and empty Win32 DLL project; name it, say, “myproxy”; drop the IDL file into the folder; and add it to the project as a source file, let’s say, it’s called my.idl. Compile it.

 

You get four more files: my_h.h, my_i.c, my_p.c and dlldata.c. Add all of them except .h file to your project. Now, try to build the project…

 

Oops…

 

“Fatal error C1189: #error : You need a Windows 2000 or later to run this stub because it uses these features: /robust command line switch.”

 

Of course, you can go to project properties, MIDL compiler and uncheck “Validate Parameters”, but generally /robust flag is a very good thing, so unless you plan to run the object on anything before Windows 2000, you better just set the compiler flag saying that. Go to project properties, C/C++, Preprocessor, Preprocessor Definitions and add “;_WIN32_WINNT=0x0500” in the end of the line. Try to build again…

 

Now you should get a bunch of linker errors. Why that? That’s because you are missing COM runtime library in your project. Go to project properties again, Linker, Input, Additional Dependencies, and add rpcrt4.lib to the line (it should be empty anyway, but if there is anything there, just add “rpcrt4.lib” to the list). Try to build again.

 

Now, it should succeed. Are you done? Not quite. Yes, myproxy.dll is successfully built. But it needs to be registered. This may be done from a command line with regsvr32:

 

Regsvr32 myproxy.dll

 

Oops, again:

 

MyProxy.dll was loaded, but the DllRegisterServer entry point was not found.

This file can not be registered.

 

What happened now? You forgot a .def file that tell to export DLL entry points. You can create it in notepad. Call it myproxy.def, open it in notepad, and type in:

 

; MyProxy.def

LIBRARY MyProxy.dll

EXPORTS

            DllGetClassObject PRIVATE

            DllCanUnloadNow PRIVATE

            DllRegisterServer PRIVATE

            DllUnregisterServer PRIVATE

 

Now, you need VS to pick it up. Go to project properties once more, Linker, Input, Module definition file, and enter the file name there. Also, add one more C++ preprocessor directive, if it’s not there yet: “;REGISTER_PROXY_DLL”

 

Rebuild it. Register it – now it will succeed. You are done with the proxy dll.

 

Don’t forget that, in the process, your IDL was moved to a separate project within the solution, your header file (my_h.h) has moved to another folder, and you still need the header and IID definitions (my_i.c) for your main projects. Otherwise the thing should start to work.

 

Notice, that generally, you would register it with the keys in the installation module. Regsvr32 is just a development time workaround.

 

So, again, a short reminder of what you need to do:

1. Create empty DLL project
2. Set “preprocessor definition” WIN32_WINNT=0x0500 and REGISTER_PROXY_DLL
3. Add linker “additional dependency” rpcrt4.lib
4. Create a def file for your project and set it as the linker “module definition file”
5. Compile IDL and files, generated out of IDL, into a DLL
6. Register proxy DLL with regsvr32

Comments

• Anonymous
  August 27, 2006

1. Thik that it's useful.
   2. Think that MIDL compiler shold do all this stuff itself
   (create DEF-file, invoke cl and link, etc).

• Anonymous
  August 28, 2006
  PingBack from http://www.aplusproxy.com/blog/?p=18

• Anonymous
  October 05, 2006
  Thanks for this contribution. Why is this approach better than just nmake -f myProxyps.mk in a post-build step?

• Anonymous
  June 26, 2007
  Thanks a lot for this article. It allowed me to solve a very annoying problem with COM objects.

• Anonymous
  November 06, 2007
  It is good ariticle COM programmers. Thanks a lot, it help quick solve to the problem.

• Anonymous
  May 01, 2008
  The comment has been removed

• Anonymous
  July 14, 2008
  You outlined the exact problem I was having.  I wish you were the first result on google!