Ссылка на обертку x86 COM из 64-битного проекта

Question

Я создал «обертку» x86 для библиотеки x86, которую мы получили от поставщика. В основном я следовал за шагами из этого поста , а также парой ссылок для вызова COM здесь и здесь .

Я отметил Проект как "Зарегистрироваться для COM взаимодействия". Я смог найти через интерфейс COM с помощью oleview и пометил его как «Использовать суррогатный процесс». Так что, надеюсь, я хорош в этом вопросе в том, что касается настроек реестра DllSurrogate go.

Теперь я не могу получить правильную ссылку для использования x86 COM. Предположительно, я могу либо сделать прямую ссылку через COM, либо использовать tlbimp, чтобы создать сборки RCW, которые я могу использовать из своего проекта x64.

С ссылкой на COM я получаю сообщение об ошибке "Библиотека типов ActiveX был экспортирован из. NET сборки и не может быть добавлен как ссылка. "

Когда я передаю dll в tlbimp, я получаю сообщение об ошибке" TI1002: входной файл не является допустимой библиотекой типов. "

Когда я передаю tlb в tlbimp, я получаю «ошибку TI1029: библиотека типов была экспортирована из сборки CLR и не может быть повторно импортирована как сборка CLR».

Любая помощь в том, что я мог бы сделать скучаю здесь очень ценится.

Answer 1

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

Позднее связывание хорошо работало с несколькими простыми строками кода:

var type = Type.GetTypeFromProgID("ProgId");
dynamic o = Activator.CreateInstance(type);
var foo = o.DoSomething();

Раннее связывание означает, что вам понадобятся сборки RCW для ссылки. В некоторых случаях VS автоматически создает их для вас, когда вы ссылаетесь на COM-объект напрямую. Однако в этом случае создания COM из сборки. Net с последующей попыткой преобразования из COM обратно в. Net - VS считает, что вы делаете что-то круглое, и запрещает это. tlbimp выдаст вам аналогичную ошибку, если вы запустите ее в файле tlb, а не в dll.

В нашем случае мы пропустили некоторые сборки в нашем проекте-обертке, что, вероятно, приводило к сбою tlbimp при вызове с длл. Но мы решили придерживаться позднего динамического связывания c из-за нашего тривиального небольшого интерфейса.