How to register a .NET assembly in place of an exi

Question

I have to deal with a COM class which is more or less a black-box component of a bigger system. This class comes from a COM EXE and is registered in the system with a known AppID and Typelib ID.

For debugging and logging purposes, I created a mock class which implements this same interface in C#. The question is: how can I register my assembly so that when the calling application tries to instantiate the interface it will instantiate my class instead?

Edit with more information:

I have the following: GUID of the type library, GUID of the implementing class, ProgID GUID of the class. I did the following, after importing the type library:

[ComVisible(true)]
[ProgId("The.ProgId.Of.The.Old.Class")]
[Guid("{the guid of the old class}")]
public class MockImplementation : ISomething 
{
    // ...
}

I try to register my class like this:

regasm /codebase myassembly.exe

And yet, nothing happens. The application still instantiates the old class. What am I doing wrong?

Answer 1

This class comes from a COM EXE

Do keep in mind that you did not write a true substitute for an out-of-process COM server. Your replacement is an in-process server. A DLL. Their location is stored in different registry keys, out-of-proc uses the LocalServer32 key, in-proc uses the InProcServer32 key. I can't see your test code to judge which one will be used. But clearly it is the wrong one :)

Regasm.exe is a possible trouble spot as well. Do keep in mind that there are two versions of it. The 32-bit version from c:\windows\microsoft.net\framework writes the 32-bit registry keys, the 64-bit version from framework64 writes the 64-bit registry keys. Both work fine, .NET code can run in either mode, but your test app is going to use only one of them. Depends on configuration, the VS test runner defaults to 32-bit mode afaik.

Your basic trouble-shooting tool here is SysInternals' Process Monitor. It is great to see what registry keys are used both by the existing COM server and your replacement. As a starting point, observe the existing server registering itself so you know exactly what registry keys are important. Normally done by running the EXE with the /regserver command line option. Write down the CLSID, Interface and TypeLib keys you see being written.

Then just do it again when you run Regasm.exe, compare what you see with what you wrote down. Be sure to use the /codebase option so you don't depend on the GAC. Whether or not you use the /tlb option is a judgement call. Do use it at first to compare keys. With the expectation of course that you now see InProcServer32 being written instead of LocalServer32, that's inevitable.

Then do it again one more time, now running your test app. Compare what you see being read this time against your notes. You may have to whack the LocalServer32 key to prevent it from being used. Or better yet, completely unregister the old server so it cannot get in the way, typically done with /unregserver option. You have to rerun Regasm.exe to put the keys back after that.