How to centralize a .net dll (com interop) that is referenced by a VB6 dll

Question

I was given a requirement from a VB6 programmer (yes they still exist). There exists a vb6 application that uses a vb6 dll, this dll now uses a .net dll which inturn uses another .net dll. Now my requirement is that the .net dlls should work the same way a vb dll does i.e. once a vb6 dll is registered it can be used by other applications and does not need to be included when rolled out(so I am told). Is there a way to place my .net dlls so that other vb6 apps can use it. From what I've seen this only works if my .net dlls are in the same folder as my vb6 exe.

I have read this How Does a COM Program Locate a .NET DLL Registered for COM Interop?

thank you

Answer 1

COM is pretty infamous for its DLL Hell problem. Registration is global for all programs on the machine. So replacing a DLL usually ends up breaking other programs that use the COM server.

.NET has a counter-measure for that, when you run Regasm.exe to register the [ComVisible] .NET assembly then it will assume by default that you put the assembly in the GAC. Which automatically buys DLL Hell protection. It is however not uncommon, especially on your dev machine and also done by the IDE, to register the assembly with the /codebase option.

You'll now however have a new problem, the CLR has no good mechanism to locate dependent .NET assemblies. The probing path is based on the EXE, the COM client. Which is why copying your dependent assemblies into the EXE install directory works.

Which is fine for testing, but not a good generic solution you'd want to use when you deploy the server. You cannot predict exactly what EXE is going to use the COM server and where it is located. And messing with the install directory of a program owned by somebody else is often politically difficult.

Use the GAC, all problems solved.