@BaredJJ

Всем привет.

У меня был проект dll для работы с графикой на C++ и проект на C# WPF использующий это dll. Эта связка работала нормально. Я решил выделить из dll загрузку объектов в отдельную библиотеку и сделав рефакторинг, переместил часть кода в static library. Настроил все. Теперь схема проекта такая:
1. Satic library
2. Dll использует static library
3. C# импортирует dll.

Проблема заключается в том, что я получаю System.DllNotFoundException при попытке обратиться к dll в шарповом коде, хотя dll находиться в одном каталоге с exe файлом. Интересней то, что все работает корректно, если я убираю обращение к методам в static library. Я полагаю что я скорее всего как то не до конца сконфигурировал dll. Статическая библиотека и динамическая собираются без ошибок. Использую Visual Studio 2019. Есть какие ни будь мысли?

0

@oleg-m1973

Сделай консольное приложение и подключи к нему свою dll. При запуске тебе покажет, чего именно не хватает.

0

@BaredJJ

Консольное на плюсах или на шарпах?

0

@oleg-m1973

Либо открой свою dll при помощи depends.exe, посмотри от каких dll она зависит и проверь что все они есть

Добавлено через 23 секунды
На плюсах

0

@BaredJJ

Интересно. У меня статическая библиотека это обертка над assimp, который содержит исходники и lib файл. А сейчас при запуске dll у меня сообщение о том, что невозможно найти dll этой зависимости. Имя этой dll должно полностью совпадать с lib файлом assimp. Это вообще законно, я же не могу пересобрать проект под dll?

0

@oleg-m1973

Скорее всего, assimp.dll и не может найти.

0

@BaredJJ

Да это теперь понятно. Но как такое происходит? assimp.dll у меня вообще не было. Был один проект dll который включал исходники assimp и assimp.lib - все работало. Я вынес код обертки в статическую библиотеку, перенес исходники assimp и assimp.lib в новый проект. Подключил к старому проекту dll, а теперь нужна assimp.dll. Это как так получилось?

0

@oleg-m1973

Скорее всего, сначала ты линковал статическую библиотеку assimp, а потом прилинковал динамическую

0

@BaredJJ

У меня скоро мозг взорвется

Можете немного по подробней, как я могу это в принципе сделать.

0

@DrOffset

0

@BaredJJ

Тут я с вами согласен, но иногда хороший совет можно получить быстрее. Так же разборка от простого к сложному, может занять неоправданно много времени.
Мне просто не понятно что значит сначала линковал? Как я могу влиять на порядок линковки?
Так же может быть такое что lib файл был собран для линковки dll версии и при этом это могло работать когда все зависимости были в одной dll, до рефакторинга? Или это не возможно?

0

@DrOffset

BaredJJ, lib-файл может обозначать как статическую библиотеку, так и библиотеку импорта DLL.

1

@JeyCi

DLL не думает о своих зависимостях в compile-time'e, т.к. она и к ней может быть подключена к чему угодно и что угодно в run-time'e... в статической библиотеке зависимости важны и их надо описать или слинковать -static уже в compile-time'e (=compiler+linker в данном случае) , т.к. потом уже ничего к ним не подключить в run-time'e...

Добавлено через 4 минуты
(и если зависит от dll и если не собрали с флагом -static, то потом эту dll и затребует)
в смысле- сама ваша dll может затребовать свою зависимость в run-time'e ... раз она dll... что и делает

0

@BaredJJ

Хмм, это дей1ствительно интересно, так как до этого все работало. Lib файл был скомпилирован для dll и в исходниках был assimp.dll. А я могу как то сделать так, чтобы использовании моей GraphicCore.dll, включающей ObjectLoader.lib, включающей assimp.lib - assimp.dll была встроена внутрь или знала где можно искать эту dll, а то сейчас получается мне приходиться копировать assimp.dll в output directory?

0

@JeyCi

а у вас есть её статическая версия (этой либы)?.. так и собирайте вашу главную dll со всеми статическими внутри... не знаю, как там у вас в VS это делается... но на крайний случай можете использовать универсальный вариант- пропишите всё в Makefile - все подробности вашей сборки вашей dll... и собирайте make'ом

0

@BaredJJ

Понял. Попробую пересобрать под статическую либу.

0

@JeyCi

можно же даже поэтапно в Makefile сделать- скомпилировать отдельно и потом слинковать всё в dll - нужную

Добавлено через 17 минут
p.s.
вот об этом я и говорила:
ваша lib была слинкована с вашим assimp, и при этом жёстко связана с нужной dll, которую вы пихаете в C#, насколько поняла... теперь же вы пытаетесь, насколько поняла, эту lib переделать в dll => зависимости, если и смогут установиться какие-либо, то только в run-time, а в сборке ничего ни от чего не зависит...
а с вашим C# я вообще не знаю, чего вы ждёте от JIT-компилятора в run-time'e -- он не будет за MSVC выполнять его недоделанную работу (т.е. в данном случае не доработали вы, а не MSVC. - разорвав связи между 2мя dll'ями)... эти связи, мне так очень сильно кажется, в принципе можно и на уровне кода C++ оформить, не обязательно надеяться на линкер, а прямо в коде правильно LoadLibrary задействовать и правильно указатель на экспортируемые/импортируемые функции dll'и оформить ... и в любом случае не отдавать всё это (установку правильных связей/зависимостей) на откуп JIT-компилятору, который тут вообще ни при чём... имхо

0

@BaredJJ

Нет вы не правильно поняли. Изначально была dll которая использовала assimp.lib и часть иходников assimp. Эту dll использовал C# код.
Я вырезал код использующий assimp из dll и поместил его в static lib. Так же в новую библиотеку добавил зависимости assimp.lib и часть исходников assimp.
Вот после этого все перестало работать.

0

@Recrut_rf

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

Добавлено через 4 минуты
Может не все зависимости были помещены в static lib? Откуда уверенность, что dll которая использовала assimp.lib, не использует ещё что-нибудь. В C# же изначально подключается куча Dll - хотя тут я возможно и не прав, так как не специалист по шарпу - есть только небольшой опыт.

0

@BaredJJ

Я как то один раз собирал либы через CMake (cmake-gui)

0