DLL CLI / C ++ оборачивает неуправляемую DLL, сбой во время выполнения в .NET (отсутствуют файлы ieshims.dll и gpsvc.dll) - PullRequest
0 голосов
/ 25 июля 2011

Я унаследовал неуправляемую DLL (изначально созданную из кода C) и хочу использовать ее в проекте .NET.У меня есть заголовочные файлы, которые оборачивают функциональность DLL в объект типа C ++, именно эту объектно-ориентированную функциональность я хочу раскрыть.Все работает нормально, когда я #include эти файлы заголовков это в стандартном проекте C ++ (Win32) и в проекте C ++ / CLI, ссылаясь на исходную DLL.

Используя Visual C ++ Express 2010, я попытался построитьуправляемая DLL для .NET.Затем эта DLL-библиотека аварийно завершилась из-за проблем с зависимостями.Обходчик зависимостей говорит:

Предупреждение. По крайней мере один модуль зависимости задержки и загрузки не найден.

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

и жалуется, что не может найти gpsvc.dll или ieshims.dll.Я знаю, что это как-то связано с x86 против x64 (я использую Win7 на x64), но, поскольку я могу использовать DLL на своей системе в проекте C ++, я подозреваю, что должна быть возможность обернуть это в управляемую DLL для использованияв .NET на той же системе.

Большое спасибо всем, кто может предложить какую-либо информацию!

(кстати, моя цель - разработать сборку .NET вместо использования p / invoke непосредственно в исходной DLL)., поскольку он будет использоваться многими программистами на C # / VB с ограниченным опытом взаимодействия после меня)

Ответы [ 2 ]

0 голосов
/ 09 июля 2015

Как вы, Рори, упоминали в своем ответе, похоже, что решение заключается в том, что вам нужно включить ВСЕ зависимые библиотеки DLL в раздел «Ссылки» вашего приложения C # / вручную включить все библиотеки DLL в корзину C # или ту же папку, что и.exe запускается с.

Я только что столкнулся с этой проблемой с настройкой, аналогичной вашей.У меня есть следующие зависимости:

C# application -> (1) CLI Wrapper DLL -> (2) C++ Wrapper DLL -> (3) 3rd Party DLL

В разделе «Ссылки» я включил (1) CLI DLL.Я не включил (2) DLL C ++, потому что она выдает ошибку ERROR ...could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component (интерпретация: DLL C ++ не совместима с .NET / CLR).

Затем я просто предположил, что, поскольку (1) CLI DLL правильно и успешно связана с (2) C ++ DLL (я проверял это с помощью консольного приложения C ++ / CLI), приложение C # могло бы получить доступ к (2) зависимости C ++ через ссылку(1) зависимость CLI.Это было неправильно.

Я не знаю причину, почему, но приложение C # не может получить доступ к зависимостям CLI.

Мое решение было вручную включать (2)C ++ DLL в каталоге .exe. Помните, что (1) CLI DLL автоматически копируется, если Local Copy имеет значение true в приложении C #.Похоже, я не сталкивался с какими-либо проблемами с (2) C ++ DLL, ссылающейся на (3) стороннюю DLL (т.е. (3) сторонняя DLL могла находиться по указанному пути / не нуждалась в локальном копировании).

0 голосов
/ 01 августа 2011

Решение: проблема x86 / x64 - красная сельдь.У меня была цепочка зависимостей длиной в три dll.Свойство «copy local» Visual Studio для всех ссылок было установлено в true, поэтому управляемая dll, на которую я ссылался, была скопирована локально, вне ее зависимостей.

По какой-то причине я не могу понять, как установить копиюЛокальное свойство ссылки на false и удаление сделанной локальной копии не решает проблему.Мне пришлось скопировать зависимости в локальную корзину проекта C #.

Потенциальный вывод: слишком большое внимание к отсутствующим зависимостям времени вызова в модуле обхода зависимостей может привести вас в неправильном направлении.

...