Как проверить зависимость от DLL?
Иногда, когда я делаю небольшой проект, я не достаточно осторожен и случайно добавляю зависимость для DLL, о которой я не знаю. Когда я отправляю эту программу другу или другим людям, "она не работает", потому что отсутствует "какая-то DLL". Это, конечно, потому что программа может найти DLL в моей системе, но не в их.
Существует ли программа / сценарий, который может проверять исполняемый файл на наличие зависимостей DLL или выполнять программу в "чистой" среде, свободной от DLL, для тестирования, чтобы предотвратить возникновение таких проблем?
18 ответов
Попробуйте ходок зависимостей: http://www.dependencywalker.com/
dumpbin Инструменты Visual Studio (папка VC\bin) могут помочь здесь:
dumpbin /dependents your_dll_file.dll
Я могу порекомендовать интересное решение для поклонников Linux. После изучения этого решения я переключился с DependencyWalker на этот.
Вы можете использовать свой любимый ldd над Windows exe, dll,
Для этого вам нужно установить Cygwin (базовая установка, без дополнительных пакетов) в Windows, а затем просто запустить Cygwin Terminal, Теперь вы можете запускать ваши любимые команды Linux, в том числе:
$ ldd your_dll_file.dll
UPD: можно использовать ldd также через терминал git bash в Windows. Нет необходимости устанавливать cygwin в случае, если у вас уже установлен git.
Нажмите кнопку запуска, введите "dev". Запустите программу под названием "Командная строка разработчика для VS 2017"
Определите полный путь к файлу сборки, с которой вы пытаетесь работать
В открывшемся окне введите
dumpbin /dependents [path], где[path]это путь, который вы выяснили в шаге 2нажмите клавишу ввода
Бэм, у тебя есть информация о зависимости. Окно должно выглядеть так:
Мне потребовался целый гребаный час, чтобы понять. Надеюсь, это поможет кому-то в будущем.
Попробуйте зависимости , он описывается как «современный обходчик зависимостей с открытым исходным кодом».
У него есть графический интерфейс, но он также работает из командной строки с дополнительным выводом JSON!
Для рекурсивного отображения зависимостей mydll.dll до глубины 1:
Dependencies.exe -chain mydll.dll -depth 1
Пример вывода:
□ mydll.dll (ROOT) : C:/.../mydll.dll
| □ USER32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\user32.dll
| □ ADVAPI32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\advapi32.dll
| □ ole32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\ole32.dll
| □ GDI32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\gdi32.dll
| □ CRYPT32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\CRYPT32.dll
| □ Secur32.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\Secur32.dll
| □ MSVCP140D.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\MSVCP140D.dll
| □ USP10.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\USP10.dll
| □ KERNEL32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\kernel32.dll
| □ VCRUNTIME140D.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\VCRUNTIME140D.dll
| □ ucrtbased.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\ucrtbased.dll
Обратите внимание, что для получения результата может потребоваться много времени, если максимальная глубина зависимости глубокая.
- Есть программа под названием "Зависит"
- Если у вас установлен Cygwin, ничего проще, чем ldd file.exe
Самое безопасное - иметь чистую виртуальную машину, на которой вы можете протестировать свою программу. На каждой версии, которую вы хотите протестировать, восстановите ВМ к ее первоначальному чистому значению. Затем установите вашу программу, используя ее настройки, и посмотрите, работает ли она.
У длл проблем есть разные лица. Если вы используете Visual Studio и динамически связываетесь с CRT, вы должны распространять библиотеки DLL CRT. Обновите ваш VS, и вам придется распространять другую версию CRT. Недостаточно просто проверить зависимости, так как вы можете их пропустить. Выполнение полной установки на чистой машине - единственное безопасное решение, IMO.
Если вы не хотите настраивать полнофункциональную среду тестирования и использовать Windows 7, вы можете использовать XP-Mode в качестве начальной чистой машины и XP-More для дублирования виртуальной машины.
На компьютере разработчика вы можете запустить программу и запустить Sysinternals Process Explorer. В нижней панели он покажет вам загруженные библиотеки DLL и текущие пути к ним, что удобно по ряду причин. Если вы выполняете пакет развертывания, он показывает, какие библиотеки DLL указаны по неправильному пути (т. Е. Неправильно упакованы).
В настоящее время наша компания использует проекты установщика Visual Studio для обхода дерева зависимостей и вывода в виде свободных файлов программы. В VS2013 теперь это расширение: https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d. Затем мы упаковываем эти свободные файлы в более полный установщик, но, по крайней мере, эта программа установки проецирует все зависимости точка-сеть и помещает их в одну точку и предупреждает вас, когда что-то отсутствует.
NDepend уже упоминался Джесси (если вы анализируете код.NET), но давайте точно объясним, как он может помочь.
Существует ли программа / сценарий, который может проверять исполняемый файл на наличие зависимостей DLL или выполнять программу в "чистой" среде, свободной от DLL, для тестирования, чтобы предотвратить возникновение таких проблем?
На панели "Свойства проекта NDepend" вы можете определить, какие сборки приложения будут анализироваться (зеленым цветом), а NDepend выведет сборки сторонних производителей, используемые приложениями (синим цветом). Предоставляется список каталогов, в которых можно искать приложения и сторонние сборки.
Если сторонняя сборка не найдена в этих каталогах, она будет в режиме ошибки. Например, если я удаляю каталог.NET Fx C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 Я вижу, что сторонние сборки.NET Fx не разрешены:
Отказ от ответственности: я работаю на NDepend
В прошлом (например, дни WinXP), я привык зависеть от DLL Dependency Walker (зависимость.exe) и полагался на него, но бывают случаи, когда я все еще не могу определить проблему (и) DLL. В идеале мы хотели бы выяснить это перед проверкой во время выполнения проверок, но если это не решает проблему (или занимает слишком много времени), вы можете попробовать включить "оснастку загрузчика", как описано на http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx и https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886(v=vs.85).aspx и кратко упомянутый LoadLibrary терпит неудачу; GetLastError не помогает
ВНИМАНИЕ: Я в прошлом испортил свои Windows, дурачась с gflag, заставляя его ползти на колени, вы были предупреждены.
Примечание. "Привязка к загрузчику" относится к каждому процессу, поэтому включение пользовательского интерфейса не будет проверяться (используйте cdb или glfags -i).
Я написал современный
C++Утилита командной строки для поиска рекурсивных зависимостей. Он прост в использовании и выводит
JSON с ценной информацией о ссылках, сбоях загрузки и отсутствующих
DLLс.
Пожалуйста, обратитесь к инструментарию SysInternal от Microsoft по ссылке ниже, https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Перейдите в папку загрузки, откройте "Procexp64.exe" с правами администратора. Откройте "Меню поиска" -> "Найти дескриптор или DLL" или нажмите сочетание клавиш Ctrl+F.
Была ли библиотека DLL скомпилирована в «режиме отладки», а затем развернута?
Если это так, это может зависеть от версии DLL "D". Например:
MSVCP140D.dll
VCRUNTIME140D.dll
Они не будут зависимыми, если DLL построена в «режиме выпуска». Версии D не поставляются с распространяемыми компонентами Microsoft Visual C++.
Чтобы убедиться, что это так, как указывали другие:
Из Visual Studio: Инструменты -> Командная строка Visual Studio.
В командной строке запустить
dumpbin /dependentsпротив DLL.
Проект pedeps ( https://github.com/brechtsanders/pedeps) имеет инструмент командной строки (copypedeps) для копирования файлов.exe (или.dll) вместе со всеми файлами, от которых он зависит. Если вы сделаете это в системе, в которой работает приложение, вы сможете отправить его со всеми библиотеками зависимостей.
Пожалуйста, поищите в файле google.exe, это небольшая утилита для этого.
Если у вас есть исходный код, вы можете использовать ndepend.
Это дорого и делает гораздо больше, чем анализ зависимостей, так что это может быть излишним для того, что вы ищете.
Для просмотра зависимостей ".dll" и другой полезной информации в Windows - я настоятельно рекомендую CFF Explorer (https://ntcore.com/?page_id=388), он бесплатный и очень полезный. Вы можете просматривать зависимости «импорт» и «экспорт» файла «.dll» и многие другие функции. И он поставляется с графическим интерфейсом, поэтому вам не нужно использовать cli ...