Search code examples
cominteropregistrationcomvisible

Register for COM Interop and ComVisible(true)


I have the common library which will be used by multiple projects. I have Signed it with Strong name in order to manage the multiple versions across the project. In this library, I have couple of classes with [ComVisble(true)] property. However, I don't want to register this library for COM interop. But I am getting compilation error which asks me to "Please register your assembly for COm Interop".

I am new to COM in .Net. I assume that only if I have [ComRegisterFunction] in my library, I need to register it for COM interop. Correct me if I am wrong.

If I register it with COM Interop, then Strong naming will not be helpful in maintaining the multiple versions across the project.

Any help in this would be greatly appreciated.


Solution

  • However, I don't want to register this library for COM interop.

    You have to register it, that's the way the client program finds your DLL. The client code uses a number when it creates the object (the CLSID guid), the registry tells which DLL implements that number. Technically the client program can use a manifest and its own local copy of your DLL but that is not under your control.

    I assume that only if I have [ComRegisterFunction] in my library,

    It is very rarely required. Only necessary if additional registry keys need to be written beyond the standard ones that Regasm.exe writes. It does not in any way address a versioning problem.

    then Strong naming will not be helpful

    A strong name permits you to put the assembly in the GAC. That actually is helpful, it avoids a new version of a DLL file overwriting an old version and ensures that an old client program that was not recompiled can still find that old version of your DLL. It is not the only technique, you can also give new versions of the DLL a different file name so they can live together in a single directory without overwriting each other. Not a very solid way to do it, programmers tend to take shortcuts when they have to fight a build system. That's a very dangerous shortcut to take. The GAC is often needed anyway, the CLR will have trouble locating dependent assemblies.

    Do keep in mind that the GAC only solves one of the DLL Hell problems associated with COM. Another very important rule in COM that interfaces and coclasses are immutable. If you make a change to one of them then you must give them a different number. This ensures that the client program cannot accidentally create an incompatible object. Very important, versioning problems are extraordinarily hard to diagnose when the client program uses early binding. Getting a different number is automatic in .NET if you don't explicitly use the [Guid] attribute on a [ComVisible] type.