Блокируют ли COM-объекты свои вызываемые библиотеки DLL во время регистрации COM?

Question

Я работаю с приложением GUI и консольной программой, которая вызывает COM-объект, который вызывает рабочую DLL. Давайте назовем их ConsoleApp, GUIApp, COM DLL и рабочая DLL. Два приложения используют CreateObject (VBasi c) или GetProcID (C#) для активации объекта COM и вызова его. В свою очередь, COM-объект вызывает Worker DLL.

Проблема: Моя цель состоит в том, чтобы зарегистрировать COM DLL один раз, а затем постоянно разрабатывать рабочую DLL без необходимости постоянно перерегистрировать COM-объект. Вещи работают как ожидалось при использовании ConsoleApp. Я могу позвонить и увидеть сообщение отладки из библиотеки Worker. Когда я изменяю сообщение и перекомпилирую работника, следующий вызов ConsoleApp показывает ожидаемое сообщение Mbox.

Но с GUIApp все работает не так, как ожидалось. Чтобы подобрать любой новый рабочий DLL-код, я должен перерегистрировать COM-объект (конечно, GUIApp не активен во время перерегистрации). Но это побуждает меня пытаться разделить большую библиотеку DLL COM + Worker на две части, чтобы избежать постоянной перерегистрации объекта COM.

Я прочитал много веб-страниц (в том числе и здесь) о COM-объектах, но не нашел ответов, которые могли бы помочь моей цели - заставить зарегистрированный COM-объект вызывать Worker DLL, которая может измениться во время разработки.

Q. Является ли это нормальным случаем, когда все библиотеки DLL, на которые ссылается и вызывает COM-объект, каким-то образом связаны с COM-объектом во время регистрации? (Ответы выше и ниже.)

Q. Могу ли я один раз зарегистрировать COM-объект и заставить его вызывать DLL, над которой я могу работать в процессе разработки, без постоянной перерегистрации COM (вызывающего) объекта каждый раз, когда я изменяю код Worker DLL?

Это моя конечная цель, если это возможно (и кажется, что она работает, как и ожидалось для ConsoleApp).

ОБНОВЛЕНИЕ: RomanR предложил мне использовать ProcessExplorer, чтобы увидеть, какой процесс зависает в Worker DLL после закрытия GUIApp вниз. Я мог найти рабочую DLL, когда GUIApp был жив, но не мог найти ее, когда GUIApp был выключен. На данный момент, очевидное доказательство ставит под сомнение мое утверждение о том, что GUIApp никогда не позволяет go Worker DLL. Мне нужно будет найти способ абсолютно точно показать, подхватывает ли GUIApp новые версии Worker DLL.

Answer 1

Проблема возникла из-за того, что я зарегистрировал COM-объект непосредственно из VStudio как часть сборки (как Администратор). В проекте COM VStudio ссылочные свойства для Worker.DLL указали Copy Local = True. Поэтому во время регистрации COM-объект ссылался на локально скопированную версию Worker.DLL, а не на будущие (впоследствии измененные) копии Worker.DLL, которые были сохранены в другом месте.

Если я установлю Copy Local = False, я мог бы зарегистрировать COM-объект, но он потерпит неудачу, потому что не смог найти Worker.DLL во время выполнения.

Самым простым решением было 1) закрыть GUIApp для освобождения библиотек COM и Worker, 2) измените библиотеку Worker новым кодом, 3) и скопируйте новую библиотеку Worker в папку COM project \ bin \ Debug, куда ее поместит операция Copy Local=True. Таким образом, зарегистрированный COM-объект получит самую последнюю рабочую DLL из ожидаемого местоположения.

Другое решение (которое я не пробовал) заключается в изменении кода COM для динамической загрузки и создания экземпляра Worker.DLL из некоторого динамического c расположения. Это также выглядит как хороший подход, хотя и не дает обратной связи во время компиляции о методах Worker DLL и т. Д. c.