Почему создание экземпляра COM-объекта в C# вызывает исключение

Question

Я пытаюсь создать экземпляр COM-объекта, определенного в dll x86, написанного на Borland C ++, в тестовой программе, которую я пишу на C# (. net 4.7.2). COM dll (сервер) работает, у меня есть сервис windows, также написанный на C ++ Borland, который может использовать его и создавать экземпляр COM-объекта из класса (используя CoCreateInstance). Библиотека DLL зарегистрирована, и запись InprocServer32 имеет правильный путь к библиотеке DLL. В библиотеке типов нет кокласса, только интерфейсы (те, которые существуют в библиотеке типов). Я использовал TlbImp для создания dll: s, на которые я ссылаюсь в проекте c#. В проекте целевая платформа установлена ​​на x86. Я пытаюсь создать экземпляр объекта:

var comType = Type.GetTypeFromProgID("ins.MyComType");
object comObj = Activator.CreateInstance(comType);

, однако вторая строка дает мне

«Исключение:« System.IO.FileNotFoundException »в mscorlib.dll» с сообщением «Получение фабрики классов COM для компонента с CLSID {C4363C5E-3831-46DF-8701-60C8D1B612BA} не удалось из-за следующей ошибки: 8007007e Указанный модуль не найден. (Исключение из HRESULT: 0x8007007E). ".

Неважно, если я попытаюсь запустить приложение от имени администратора. У меня есть смутная память о том, чтобы попробовать что-то подобное пару лет назад go и что в то время это работало. Вероятно, это было на машине с Win 7 (возможно, даже 32-битной системой). Я пытался открыть проект в DependencyWalker, но я не уверен, что я ищу at. Я получаю пару ошибок:

* Ошибка: не найдена хотя бы одна необходимая неявная или перенаправленная зависимость. * Ошибка: Обнаружены модули с разными типами ЦП. * Ошибка: циклическая зависимость Обнаружено. * Предупреждение. По крайней мере один модуль зависимости задержки загрузки не найден. * Предупреждение: По крайней мере один модуль имеет неразрешенный импорт из-за отсутствия функции экспорта в модуле, зависящем от задержки загрузки.

Кто-нибудь имеет какое-либо представление о том, что это может быть причиной исключения? Или, если бы я мог получить некоторые подсказки о том, как копать глубже в зависимом ходоке? Я получаю гигантское c дерево Системная сборка, но я не вижу какой-либо очевидной сборки, хотя DW называет многие из них 64-битными. Я думаю, что некоторые зависимые DLL где-то должен быть x86, но какой (ы). Есть ли что-нибудь подобное, что я должен был установить, чтобы это работало?

С наилучшими пожеланиями

/ Эрик

Answer 1

Вы должны написать простой VBScript, содержащий следующие строки:

set obj = CreateObject("ins.MyComType")
MsgBox TypeName(obj)

Назовите файл test.vbs

Выполните команду:

c:\windows\syswow64\wscript.exe test.vbs

Использование версия от syswow64 гарантирует, что она использует 32-разрядную версию wscript.exe, которая может создавать экземпляры 32-разрядных объектов COM. Версия в c: \ windows \ system32 может создавать экземпляры только 64-битных внутрипроцессных COM-объектов в DLL-файлах ... вы сказали, что ваш объект является 32-битным COM-сервером DLL.

Если сбой vbscript Возможно, объект не совместим с автоматизацией - реализует IDispatch. В противном случае вы получите сообщение об ошибке, из-за которого произойдет сбой.

Если это удастся, вы будете знать, что на стороне C ++, вероятно, нет никаких проблем, вызывающих проблемы. Вы ДУМАЕТЕ, что это так ... но где же среда исполнения Borland C ++? Все ли статически связано или некоторые динамически связаны? Если он динамически связан, где он находится в пути? Может случиться так, что у вашей службы C ++ есть библиотека в своем пути, так что когда она загружает ваш COM-объект, библиотека становится доступной. Но когда вы пытаетесь загрузить программу от стороннего производителя, например. NET или VBScript, путь к библиотеке проявляется. Кто знает? Я просто делаю предложения.

Если вы используете ProcMon, он может увидеть, где проблемы. Он покажет вам, какие записи реестра читаются и какие файлы пытаются загрузить.