Как программа COM находит .NET DLL, зарегистрированную для взаимодействия COM? - PullRequest
7 голосов
/ 19 мая 2010

Один клиент хочет использовать наши .NET DLL из VB6. Они предназначены для поддержки обратного взаимодействия, и все работает нормально ... за исключением: есть две отдельные программы VB6 в двух разных каталогах. Кажется, необходимо сделать одно из:

  1. Скопируйте .NET DLL в обе директории или
  2. Установите .NET DLL в GAC

Это наблюдение клиента, которое также подтверждается документацией RegAsm :

После регистрации сборки с помощью Regasm.exe, вы можете установить его в глобальный кеш сборок, чтобы он мог быть активирован с любого COM-клиента. Если собрание только будет активируется одним приложением, вы может разместить его в этом приложении каталог.

Я запутался в этом вопросе.

Первая точка путаницы:

Насколько я понимаю, среда выполнения COM находит DLL с помощью идентификатора программы / идентификатора класса. Когда я просматриваю в реестре запись Class ID, я вижу полный путь к .NET DLL в ключе CodeBase. Почему COM-программа, использующая Prog ID / Class ID, не находит .NET DLL с помощью CodeBase?

Второй пункт путаницы:

GAC относится только к .NET. Как это связано с разрешением COM-ссылок?

1 Ответ

7 голосов
/ 15 октября 2010

Вы правы. COM использует ProgId, чтобы добраться до ClassId, чтобы добраться до COM-сервера для загрузки. В случае DLL-библиотек .NET COM-сервер фактически является MSCOREE, а не .NET-библиотекой (значение ключа по умолчанию в {CLSID} / localserver32). MSCOREE, а не COM, затем может использовать любые правила, которые он хочет найти для сборки .NET.

На данный момент я не знаю, что на самом деле делает .NET - это потребует тестирования. Вы можете наблюдать за собой, используя FUSLOGVW . Однако я могу догадаться, что он загружает сборку так же, как и любую другую сборку .NET.

Предполагая, что он просто вызывает Assembly.Load () со значением ClassName, он будет следовать правилам .NET . Сначала посмотрите в GAC, если не найден, будет проверять - поэтому, если определена кодовая база, он будет только там смотреть, иначе он будет проверять на основе базы приложения (по умолчанию каталог приложения [, но не для ASP.NET). ]).

Я думаю, что это соответствует тому, что вы читаете в регазме.

Ваш вопрос настолько старый, что, я полагаю, это был OBE , но правила, которые вы использовали бы для размещения сборок в каталоге приложения , , используют кодовую базу или в GAC совпадают с и без взаимодействия. Каждая ситуация отличается, и я не сделал достаточно .NET, чтобы отказаться от каких-либо глубоких идей. Я предпочитаю установки xcopy, так что я бы пошел в каталог приложения (и использовал без регистрации COM ), но есть и другие соображения, например, если два приложения vb должны использовать одну и ту же версию объекта COM.

...