Первоначальная проблема заключается в том, что я попытался перестроить проект C ++ с символами отладки и скопировал его на тестовую машину. Выходные данные проекта - внешний COM-сервер (файл .exe).
При вызове функции интерфейса COM происходит сбой вызова RPC:
COMException (0x800706BE): сбой удаленного вызова процедуры.
Согласно проекту COM HRESULT, если код FACILITY равен 7, это на самом деле ошибка WIN32, а код ошибки win32 - 0x6BE, что является упомянутым выше «удаленным вызовом процедуры».
Все, что я делаю, это заменяю файл .exe сервера COM, исходный файл работает хорошо.
Когда я зарегистрировался в проекте, я обнаружил, что это проект C ++ с управляемым расширением.
Когда я проверяю DLL с отражателем, он показывает, что есть еще 2 ссылки на сборку .NET.
Затем я проверил настройки проекта и ничего не нашел о дополнительных 2 сборочных ссылках.
Я включил шоу, включающее опцию компилятора и подробную библиотеку компоновщика, и попытался
проанализировать, ссылаются ли на сборку косвенно через файл .h.
Я собрал весь файл .h и grep для всех файлов с помощью '#using' '#import' и самого файла сборки.
Действительно, в одном из файлов .h присутствует «#using», но оно не относится к указанной сборке.
А что касается связанных библиотечных файлов .lib, то только один из .lib-файлов является побочным продуктом другого проекта C ++ с поддержкой управляемых расширений, все остальные создаются чистым традиционным проектом C ++. Для проекта C ++ с управляемыми расширениями я проверил выходную сборку DLL, она НЕ ссылалась на сборку 2.
Я даже пытаюсь получить доступ к дополнительному файлу сборки через filemon и procmon sysinternal, но процесс перестройки НЕ получает доступ к этому файлу.
Я очень озадачен моделью процесса компиляции и компоновки проекта VC ++ / CLI, где дополнительная ссылка на сборку просочилась в финальную сборку?
Заранее благодарим за любую вашу помощь.