C# COM-Interop dll для C++ COM dll не работает между двумя решениями

Question

Я пытаюсь повторно использовать библиотеку interop, которая скомпилирована в одном проекте на другом, и она не работает.

Я подробно:

• Я скомпилировать C++ COM DLL native_com_object.dll
• В том же растворе, у меня есть C# проект под названием LocalComClient.dll, который генерирует Interop.native_com_objectLib.dll использовать C++ native_com_object.dll.
• Последнее, у меня есть другое решение с проектом C# (скомпилировано на другом компьютере) под названием RemoteComClient.dll, которое ссылается на native_com_object.dll (зарегистрировано на этом компьютере). Это создает другой файл Interop.native_com_objectLib.dll.

Проблема заключается в том RemoteComClient.dll пытается загрузить native_com_object.dll это MUST использовать свой Interop. Если я пытаюсь использовать LocalComClient.dll Interop .Net не удается загрузить сборку.

Edit: Точное сообщение исключение я получаю:

Could not load file or assembly 'Interop.native_com_objectLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Конечно проблема возникает также наоборот (LocalComClient не может использовать Interop RemoteComClient в).

Мой первый вопрос - почему? Насколько я понимаю, он должен генерировать тот же interop (который, очевидно, я ошибаюсь).

Мой второй вопрос: возможно ли сделать один обмен для всех .Net-клиентов DLL?

Я укажу, что я использую VS2013 (обе машины), объекты C# - AnyCPU, а C++ - x64.

Important EDIT: Я не могу вставлять типы взаимодействия, потому что проекты C# являются .Net 3.5 (не 4).

Answer 1

Определение манифеста размещенной сборки не соответствует ссылке на сборку.

Очень распространенное сообщение об исключении, DLL, которое он находит во время выполнения, не совпадает с эталонной сборкой, с которой была скомпилирована ваша программа. Проблема с базой DLL Hell, а не специфическая для COM-взаимодействия.

Вы диагностируете подобные сбои с помощью Fuslogvw.exe, его трассировка для неудачной сборки сборок показывает, что она искала и что она обнаружила. Обычное несоответствие - это номер версии, вы скомпилировали свою программу с версией промежуточной сборки 1.0.0.0. Эта версия создается из номера версии библиотеки типов COM-сервера. Вы использовали версию 1.0, kaboom, если COM-сервер изменился, и вы используете его новую сборку interop.

И publicKeyToken может быть легко несоответствием, вы ожидаете, что в DLL-интерфейсе не будет такого. Kaboom, если тот, который вы загружаете во время выполнения, имеет один. Не очень редко в COM-взаимодействии, вы, как правило, предпочитаете хранить их в GAC, и для этого требуется сильное имя. То, что вы обычно делаете позже, забывая перестроить приложение, является легкой ошибкой.

Решение состоит в том, чтобы перестроить клиентское приложение с помощью правильной сборки взаимодействия.