Do COM objects lock their called DLLs at COM registration time? - com

Question

I am working with an application GUI program and a console program, which call a COM object, which calls a worker DLL. Let’s call them ConsoleApp, GUIApp, COM DLL, and Worker DLL. The two Apps use CreateObject (VBasic) or GetProcID(C#) to activate the COM object and call it. In turn, the COM object calls the Worker DLL.
Problem: My goal is to register the COM DLL once, and then to continually develop the worker DLL without having to reregister the COM object all the time. Things work as expected when using the ConsoleApp. I can call it and see a debug message from the Worker DLL. When I change the message and recompile the worker, the next invocation of ConsoleApp shows the expected Mbox message.
But things do not work as expected with the GUIApp. To pick up any new worker DLL code, I must reregister the COM object (of course the GUIApp is not alive during re-registration). But that defeats the purpose of me trying to split the big COM+Worker DLL into two pieces to avoid re-registering the COM object all the time.
I have read many web pages (including here) on COM objects, but have not found answers that might work for my goal of having the registered COM object call a Worker DLL that can change during development.
Q. Is this the normal case that all DLLs referenced and called by a COM object are somehow bound to the COM object at registration time? (Answered above and below.)
Q. Is there any way for me to register the COM object once and have it call a DLL that I can work on in development without constant reregistering the COM (calling) object every time I change the Worker DLL code?
That's my ultimate goal if it is possible (and it seems to work as expected for the ConsoleApp).
UPDATE: RomanR suggested that I use ProcessExplorer to see which process is hanging on to the Worker DLL once GUIApp has been shut down. I could find the Worker DLL when GUIApp was alive but could not find it when GUIApp was shutdown. At the moment, the visible evidence is questioning my statement that the GUIApp never lets go of the Worker DLL. I will have to figure out a way of absolutely showing whether rebooting GUIApp picks up the new versions of Worker DLL.

Answer 1

The problem occurred because I registered the COM object direct from VStudio as part of the build (as Administrator). In the COM VStudio project, the reference properties for Worker.DLL specified Copy Local = True. Therefore, at the time of registration, the COM object was referencing the locally-copied version of Worker.DLL and not the future (later modified) copies of Worker.DLL that were stored elsewhere.
If I set Copy Local = False, I could register the COM object, but it would fail because it could not find the Worker.DLL at runtime.
The easiest solution was to 1) close the GUIApp to release the COM and Worker DLLs, 2) modify the Worker DLL with new code, 3) and copy the new Worker DLL into the COM project\bin\Debug folder where the Copy Local=True operation would put it. That way the registered COM object would pick up the most recent Worker DLL from the expected location.
Another solution (that I have not tried) is to modify the COM code to dynamically load and instantiate Worker.DLL from some dynamic location. That looks like a good approach too, although it does not give compile-time feedback on Worker DLL methods, etc.