We have an old C/C++ .dll that a customer accesses via COM.
We have tried to replace our old .dll with a new one written i .NET.
Customer cannot recompile their client so it is important that the old .dll can be replaced simply by COM unregister / register new (using regsvr32 / regasm).
We believe we have built the .NET .dll with the same COM interface as the old; GUID’s, names, dispid’s etc. all match. We have verified this by writing our own C++ test application and it continues to work when we unregister old .dll / register new one.
The problem is that the customer’s client failes to start.
Strangely if we leave the old .dll registered (e.g. both .dll’s are registerd) it works; The customer’s application starts and calls methods in our new .dll. But as soon as we unregister the old .dll the application fails to start again.
We have tried different ways to register the new .dll; using regasm with /codebase option, /tbl, etc.
If I inspect with OLE/COM Viewer I can see some minor differences between new and old .dll, for example the type library “name” differs. But I suppose since our own C++ test client works with either .dll the COM interfaces are enough similar?
Please, anyone has any idea? How is it possible for one C++ client to load with our new .dll while another fails? Why do both work if we leave the old .dll registered in parallel to the new one? Is there any explanation why the two C++ clients behave differently?
UPDATE:
The error message in the client says:
“failed when running: CLSIDFromProgID. Check if [myDll].dll is registered.”
Kind Regards P.T
There are many possibilities. First, ensure you are registering the type library of your new DLL. The old one may be doing it as part of DllRegisterServer, but AFAIK, .Net DLLs do not. Register it with REGTLB.exe.
Also check the threading models are the same in both DLLs.
If neither of those help, I suggest you keep on until OLEVIEW says they are identical – you never know what the client is doing which is different from yours.