Как проверить зависимость от DLL?
иногда, когда я делаю небольшой проект, я недостаточно осторожен и случайно добавляю зависимость для DLL, о которой я не знаю. Когда я отправляю эту программу другу или другим людям, "это не работает", потому что "некоторые DLL" отсутствуют. Это, конечно, потому что программа может найти DLL на моей системе, но не на их.
есть ли программа / скрипт, который может сканировать исполняемый файл для зависимостей DLL или выполнять программу в "чистой" среде без DLL для тестирования предотвратите эти упс ситуациях?
10 ответов:
попробуйте dependency walker:http://www.dependencywalker.com/
dumpbinиз Visual Studio tools (VC\bin папка) может помочь здесь:dumpbin /dependents your_dll_file.dll
Я могу порекомендовать интересное решение для поклонников Linux. После того, как я изучил это решение, я переключился с DependencyWalker на это.
вы можете использовать ваш любимый
lddпо сравнению с Windows, связанные сexe,dll.для этого Вам необходимо установить программа (базовая установка, без каких-либо дополнительных пакетов не требуется) на вашем Windows, а затем просто запустите
Cygwin Terminal. Теперь вы можете запускать свои любимые команды Linux, в том числе:$ ldd your_dll_file.dllUPD: можно использовать
lddи через Git Bash terminal на Windows. Нет необходимости устанавливать cygwin в случае, если у вас уже установлен git.
- есть программа под названием "зависимость"
- Если у вас установлен cygwin, ничего проще, чем файл ldd.exe
самое безопасное-иметь чистую виртуальную машину, на которой вы можете проверить свою программу. В каждой версии, которую вы хотите протестировать, восстановите виртуальную машину до ее начального чистого значения. Затем установите программу с помощью ее установки и посмотрите, работает ли она.
проблемы Dll имеют разные лица. Если вы используете Visual Studio и динамически подключаетесь к CRT, вам нужно распространять библиотеки DLL 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=vs.85). aspx и кратко упоминается LoadLibrary терпит неудачу; GetLastError не помогает
предупреждение: Я испортил свои окна в прошлом дурачась с gflag заставляя его ползти на колени, вы были предупреждены.
Примечание: "Loader snap" для каждого процесса, поэтому UI enable не будет оставаться проверенным (используйте cdb или glfags-i)
Если у вас есть исходный код, вы можете использовать ndepend.
Это дорого и делает намного больше, чем анализ зависимостей, поэтому это может быть излишним для того, что вы ищете.
NDepend уже упоминался Джесси (если вы анализируете .NET-код), но давайте объясним, как именно это может помочь.
есть ли программа/скрипт, который может сканировать исполняемый файл для DLL зависимости или выполнение программы в "чистой" среде без DLL для тестирования, чтобы предотвратить эти ситуации упс?
на панели свойств проекта NDepend можно определить, какие сборки приложения следует анализировать (зеленым цветом) и вопросом, что происходит предположит Сторонние сборки, используемые приложениями (в синем). Список каталогов, в которых выполняется поиск приложений и сторонних сборок.
если сторонняя сборка не найдена в этих каталогах, она будет находиться в режиме ошибки. Например, если я удалю каталог .NET Fx
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319Я вижу, что .NET Fx сторонних сборок нет решено:отказ от ответственности: я работаю на NDepend



Comments