Как проверить зависимость DLL?

Ответ 1

Попробуйте Dependency Walker (последнее обновление в 2006 г.) или его современную переписку под названием Dependencies.

Ответ 2

dumpbin из инструментов Visual Studio (папка VC\bin) может помочь здесь:

dumpbin /dependents your_dll_file.dll

Ответ 3

Я могу порекомендовать интересное решение для поклонников Linux. После изучения этого решения я переключился с DependencyWalker на этот.

Вы можете использовать свой любимый ldd поверх Windows, связанных с exe, dll.

Для этого вам нужно установить Cygwin (базовая установка, без дополнительных пакетов) в Windows, а затем просто запустить Cygwin Terminal. Теперь вы можете запускать ваши любимые команды Linux, в том числе:

$ ldd your_dll_file.dll

UPD: Вы можете использовать ldd также через терминал git bash в Windows. Нет необходимости устанавливать cygwin в случае, если у вас уже установлен git.

Ответ 4

1. Нажмите кнопку запуска, введите "dev". Запустите программу под названием "Командная строка разработчика для VS 2017"

2. Определите полный путь к файлу сборки, с которой вы пытаетесь работать

3. В открывшемся окне введите dumpbin/dependents [path], где [path] - это путь, который вы нашли в шаге 2

4. нажмите клавишу ввода

Бэм, у тебя есть информация о зависимости. Окно должно выглядеть так:

Ответ 5

• Существует программа под названием "Зависит"
• Если у вас установлен cygwin, ничего проще, чем ldd file.exe

Ответ 6

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

Проблемы с Dll имеют разные грани. Если вы используете Visual Studio и динамически связываетесь с CRT, вам необходимо распространять DLL-библиотеки CRT. Обновите свой VS, и вы должны распространять другую версию CRT. Просто проверки зависимостей недостаточно, так как вы можете пропустить их. Выполнение полной установки на чистой машине - единственное безопасное решение, IMO.

Если вы не хотите настраивать полноценную тестовую среду и иметь Windows 7, вы можете использовать XP-Mode в качестве начальной чистой машины и XP-More, чтобы дублировать виртуальную машину.

Ответ 7

На вашей машине разработки вы можете выполнить программу и запустить Sysinternals Process Explorer. В нижней панели он покажет вам загруженные DLL и текущие пути к ним, что удобно по ряду причин. Если вы выполняете свой пакет развертывания, он будет показывать, какие DLL-ссылки ссылаются на неправильный путь (т.е. Не были правильно упакованы).

В настоящее время наша компания использует проекты установщика Visual Studio для работы с деревом зависимостей и вывода в виде незакрепленных файлов программы. В VS2013 это теперь расширение: https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d. Затем мы упаковываем эти незакрепленные файлы в более полный инсталлятор, но, по крайней мере, этот проект устанавливает все зависимости от сетки точек и помещает их в одно место и предупреждает вас, когда что-то не хватает.

Ответ 8

В прошлом (т.е. дни WinXP) я использовал/полагался на DLL Dependency Walker (depend.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)

Ответ 9

Пожалуйста, найдите "depend.exe" в google, это крошечная утилита для обработки этого.

Ответ 10

Если у вас есть исходный код, вы можете использовать ndepend.

http://www.ndepend.com/

Это дорого и делает намного больше, чем анализ зависимостей, поэтому он может быть излишним для того, что вы ищете.

Ответ 11

NDepend уже упоминался Джесси (если вы анализируете .NET-код), но позволяет точно объяснить, как это может помочь.

Есть ли программа / script, которая может сканировать исполняемый файл для DLL зависимостей или выполнить программу в "чистой" среде без DLL для тестирования для предотвращения таких ситуаций?

На панели "Свойства проекта NDepend" вы можете определить, какие анализы приложений собираются (зеленым цветом), а NDepend будет выводить сторонние сборки, используемые приложениями (синим цветом). Предоставляется список каталогов, где можно искать приложения и сторонние сборки.

Если сторонняя сборка не найдена в этих каталогах, она будет в режиме ошибки. Например, если я удалю каталог .NET Fx C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319, я вижу, что сторонние сборки .NET Fx не разрешены:

Отказ от ответственности: я работаю для NDepend

Ответ 12

Пожалуйста, обратитесь к инструментарию SysInternal от Microsoft по ссылке ниже, https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

Перейдите в папку загрузки, откройте "Procexp64.exe" с правами администратора. Откройте параметр "Найти Menu->" Найти дескриптор или DLL "или комбинацию клавиш Ctrl + F.

Ответ 13

Попробуйте JetBrains dotPeek. Это бесплатно.

Ответ 14

Проект pedeps (https://github.com/brechtsanders/pedeps) имеет инструмент командной строки (copypedeps) для копирования файлов .exe (или .dll) вместе со всеми файлами, от которых он зависит. Если вы сделаете это в системе, в которой работает приложение, вы сможете отправить его со всеми зависимыми DLL-библиотеками.