Приложение не видит dll

[Sergey Puzanov]

Давно мучаюсь с этой проблемой, прочитал много тем здесь, но нужной не нашёл.
Имеется Windows 7 х32, LabView 2018, установленные два драйвера на модули hpe1419 и hpe1459 (пока что рассмотрим только его, для второго решение совпадёт), а также файлы типа .dll, .fp, .h, причём при установке драйверов файлы .dll кладутся в определённую папку, находящуюся в C:\Program Files\IVI Foundation\и т.д. Дальше с помощью Driver Import Wizard, используя эти самые файлы .fp, .h и .dll я создаю драйвер именно уже для самого LabView, причём .dll перенёс в папку с проектом. На этом компе не было необходимости следить, какие пути куда ведут - работает и хорошо. Вот как выглядит структура проекта:

Теперь необходимо создать .exe файл и запустить приложение на другом компе. Я добавлял в "всегда включено" эту библиотеку, закидывал сразу в корень к экзешнику, добавлял другие библиотеки, которые возможно могли быть связаны с этой, устанавливал драйверы на другой комп, но всё равно одна и та же ошибка - Missing external function *название библиотеки и виаек*. Так выглядит всё при создании:

Как правильно это сделать? Спасибо.

[Artem.spb]

А как выглядит вызов dll? (настройки)
Попробуйте НЕ включать их в билдер. Я никогда этого не делал, система сама знает, что ей эти файлы нужны и кладёт куда надо, и, соответственно, знает, где они лежат.

[Sergey Puzanov]

А как выглядит вызов dll? (настройки)

Например, инициализация:

Попробуйте НЕ включать их в билдер. Я никогда этого не делал, система сама знает, что ей эти файлы нужны и кладёт куда надо, и, соответственно, знает, где они лежат.

Да, положила сама, но ошибка осталась.

DLLerror.png (8.06 КБ) 3180 просмотров

[ujin1]

В ОС есть порядок опроса путей при вызове *.dll.
В типичных случаях этот файл размещается в том же каталоге, что и приложение, которое будет его использовать, и приложение загружает DLL в процессе своей инициализации. Вторым возможным местом расположения DLL является рабочий каталог, а далее ОС будет осуществлять поиск .DLL-файла в системном каталоге, каталоге Windows, а также в путях доступа, указанных в переменной окружения PATH.
В Линукс соответственно пути другие. В NI LinuxRT пути отличаются от допустим CENTOS.
Я убрал все пути из вызова dll и указание расширения, чтобы подходило и *.dll и *.so

Далее поместил библиотеки в C:\Program Files (x86)\National Instruments\LabVIEW 2019\resource
На том компьютере, котором исполняется программа положил библиотеки в тот же каталог что и приложение.
В линукс расположение библиотек в рабочем каталоге и подкаталоге /data так же как и символических ссылок не работает(хотя указан этот способ). Нужно размещать в каталоге библиотек В NILinuxRT это /usr/lib/
Labview при компиляции, если не включать явно, размещает .dll в подкаталоге /data рабочего каталога и в Windows это у меня везде работало. Возможно не добавлены зависимые библиотеки, хотя Вы указали что добавлены.
Кроме путей есть методы вызова и разная разрядность приложения на компьютере разработки и на компьютере исполнения.
Еще один метод создать инсталлятор приложения и включить в него инсталлятор драйверов. Так как работа идет с драйверами железа возможно требуется установить эти драйверы на целевой платформе.

[Sergey Puzanov]

Всё, теперь разобрался, спасибо. Проблема действительно состояла из нескольких частей - и путь библиотеки был указан относительно основного компа, и разрядности систем были разными, хотя сама dll одна и та же, и сам инсталятор драйвера тоже устанавливает его на обе системы.

[Agat]

Помогите разобраться с похожей проблемой:
Имеется VI в котором SubVI вызывают dll. В режиме разработки все работает отлично. Но когда запускаю exeшник - программа не может найти dll, хотя он лижит в папке data. Соответственно выкидывает окно проводника в котором остается только выбрать искомый dll и все запускается

. Вопрос почему она не видит dll? Пробовал перекинуть его из data рядом с VI, тогда при запуске "теряются" SubVI и надо указывать вручную в папку data, где они лежат.. В настройках все dll всегда включены в data, SubVI так же всегда включены

[Sergey Puzanov]

Помогите разобраться с похожей проблемой

Так вроде решение, предложенное ujin1, Вами не испытывалось - на последнем скриншоте путь к библиотеке выставить не прямой, а просто "AgInfiniiVision.dll", и при компиляции .exe файла он сам подтянет все нужные библиотеки, не нужно будет их специально добавлять.

[Agat]

Так вроде решение, предложенное ujin1, Вами не испытывалось - на последнем скриншоте путь к библиотеке выставить не прямой, а просто "AgInfiniiVision.dll", и при компиляции .exe файла он сам подтянет все нужные библиотеки, не нужно будет их специально добавлять.

просто имя заменяется само на полный путь при сохранении..

[Artem.spb]

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

[Agat]

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

Пробовал, в этом случае он не появляется в папке data и , соответственно, при запуске ехешника также открывается проводник для ручного выбора.

[ujin1]

Помогите разобраться с похожей проблемой:
Имеется VI в котором SubVI вызывают dll. В режиме разработки все работает отлично. Но когда запускаю exeшник - программа не может найти dll, хотя он лижит в папке data. Соответственно выкидывает окно проводника в котором остается только выбрать искомый dll и все запускается 1.jpg. Вопрос почему она не видит dll? Пробовал перекинуть его из data рядом с VI, тогда при запуске "теряются" SubVI и надо указывать вручную в папку data, где они лежат.. В настройках все dll всегда включены в data, SubVI так же всегда включены 2.jpg3.jpg4.jpg5.jpg

Меня смущают 2 звездочки в конце имени файла dll.
AgInfiniiVision**.dll. Звездочки в именах обычно обозначают любое количество любых символов. Так Windows не понять, что искать
AgInfiniiVision.* - Расширение звездочка в данном случае LabVIEW воспринимает либо .so либо .dll. Если не планируется использование библиотеки с этим названием на Linux и Windows лучше оставить .dll.

[Agat]

Методом тыка удалось собрать рабочий ехешник, но не долго счастье длилось.. Следующие попытки создать ехе выдают такую ошибку

Незнаю связано ли это с тем что я наковырял, а именно - в настройках build дирректорию support объеденил с главной, dll и все subvi легли вместе с ехешником и больше при запуске программа про него не вспоминала, но в этом случае перестала видеть subvi (которые лежат в этой же папке) и тогда я сделал вот что

со всеми subvi, после чего ехешник собрался и запустился без проблем, но потом понадобилось собрать ехе заново и облом... выдает страшную ошибку, хотя файлы указанные в ней я не трогал..

[Agat]

Меня смущают 2 звездочки в конце имени файла dll.
AgInfiniiVision**.dll. Звездочки в именах обычно обозначают любое количество любых символов. Так Windows не понять, что искать
AgInfiniiVision.* - Расширение звездочка в данном случае LabVIEW воспринимает либо .so либо .dll. Если не планируется использование библиотеки с этим названием на Linux и Windows лучше оставить .dll.

Это не имеет значения, т.к. и в случае AgInfiniiVision**.dll и AgInfiniiVision.dll после сохранения VI, имя автоматом меняется на полный путь.

[ujin1]

Методом тыка удалось собрать рабочий ехешник, но не долго счастье длилось.. Следующие попытки создать ехе выдают такую ошибку 1.jpg2.jpg
Незнаю связано ли это с тем что я наковырял, а именно - в настройках build дирректорию support объеденил с главной, dll и все subvi легли вместе с ехешником и больше при запуске программа про него не вспоминала, но в этом случае перестала видеть subvi (которые лежат в этой же папке) и тогда я сделал вот что 0.jpg со всеми subvi, после чего ехешник собрался и запустился без проблем, но потом понадобилось собрать ехе заново и облом... выдает страшную ошибку, хотя файлы указанные в ней я не трогал..

Отключите синхронизацию с облаком, перезагрузите LabVIEW, перезагрузите компьютер. При закрытии LabVIEW выдает ошибку? Возможно какой то из SubVI не остановил работу.

[Agat]

Ошибку builderа победил. Но меня очень интересует один вопрос - почему если в настройках subvi не включать ее в вызывающую vi, то после компиляции и запуска ехешника программа не может их (subvi) найти сама и выдает окно проводника? хотя все файлы были всегда включены в билд и лежат вместе с ехешником