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

dumpbin из Visual Studio tools (папка 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.

1. существует программа под названием "зависит"
2. Если у вас установлен cygwin, ничего проще, чем файл ldd.exe

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

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

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

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

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

в прошлом (т. е. 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=против 85).aspx и кратко упомянутый LoadLibrary терпит неудачу; GetLastError нет помощи

предупреждение: Я испортил свои окна в прошлом, дурачась с gflag, заставляя его ползать на колени, вы были предупреждены.

Примечание: "Loader snap" для каждого процесса, поэтому UI enable не будет оставаться проверенным (используйте cdb или glfags-i)

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

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

http://www.ndepend.com/

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

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

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

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

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

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