Определить, какие файлы DLL и / или OCX фактически используются моей программой?

Мое программное обеспечение написано на VB6. В целях диагностики мне нужно определить фактические файлы DLL / OCX, которые загружаются и используются приложением на компьютере клиента.

Поскольку библиотеки VB6 (включая файлы OCX) являются библиотеками COM, они загружаются косвенным образом на основе информации в реестре. Это означает, что возможно использование файла, отличного от того, который использовался в средах разработки / тестирования. Иногда в клиентской среде это может привести к сбоям, которые трудно диагностировать без этой информации.

(Мой план состоит в том, чтобы построить диагностическое окно для чтения в моей программе, которое показывает библиотеки, которые программа использует в данный момент.)

Источник

2 ответа

Решение

Существует множество способов установить зависимости времени выполнения от DLL (или файлов OCX). В идеале вам нужно будет учесть все из них:

Этот ответ специфичен для VB6, но многие другие языки программирования будут работать аналогично.

Механизмы, которые устанавливают зависимости во время выполнения:

Во время компиляции для традиционных динамически связанных библиотек (DLL, которые не являются COM)

  • Файлы (как следует из их названия) динамически загружаются во время выполнения на основе процесса компоновки, выполненного в конце компиляции
  • Это включает в себя код VB6, который использовал такой оператор, как: Declare Function … Lib …
  • (В.NET это будет означать вызов "нативного кода")
  • Для идентификации: проверьте исходный код.
  • Для идентификации без источников: они могут быть обнаружены с помощью такого инструмента, как Dependency Walker

Во время компиляции для COM DLL

  • В VB6 это известно как "раннее связывание".
  • Это включает в себя код VB6, который явно установил ссылку на DLL или OCX.
  • Обратите внимание, что зависимость на самом деле зависит от класса COM или интерфейса GUID, а не явно от самого файла DLL.
  • Для идентификации: они перечислены в проекте VBP.
  • Чтобы определить (альтернативно): Если у вас нет VBP или исходного кода, эти зависимости обычно могут быть выявлены с помощью IMPORT заявления в OLEView. Вам может потребоваться найти некоторые GUID оттуда в реестре, чтобы увидеть, какие фактические файлы DLL используются.

Во время компиляции для статически связанных библиотек (не COM, не DLL)

  • Библиотечный код включен в EXE или DLL, которая компилируется. Следовательно, нет никакой зависимости во время выполнения от чего-либо внешнего.
  • Насколько я знаю, это невозможно для программ VB6. Что-то вроде компоновщика C может использовать такие библиотеки. Грубый эквивалент в.NET будет использовать ILMerge для объединения сборок.

Во время выполнения для традиционных DLL (не COM)

  • DLL могут быть загружены произвольно, используя Win32 API, например LoadLibrary(),
  • Чтобы определить: вы должны посмотреть на источник, чтобы знать, что может произойти.
  • С другой стороны, если у вас нет источника, вы можете использовать такие инструменты, как Process Explorer и / или Process Monitor, чтобы наблюдать за работающим экземпляром и видеть, какие библиотеки DLL действительно загружаются.

Во время выполнения для COM DLL

  • Классы могут быть загружены произвольно с использованием, например, VB6 CreateObject() звонки.
  • В VB6 это известно как "позднее связывание"
  • Какая DLL будет использоваться для предоставления класса, будет определяться контекстом активации процесса. Контекст активации устанавливается файлом манифеста приложения (если он есть) или реестром Windows в противном случае (обычное значение по умолчанию для программ VB6).
  • Чтобы определить: вы должны посмотреть на источник, чтобы знать, что может произойти. Вам также необходимо знать, какое состояние конфигурации будет на ПК, на котором выполняется код - какие файлы DLL зарегистрированы, при условии, что манифест не используется.
  • Альтернатива без исходного кода: как в случае выше

Важно: зависимости могут быть связаны. Поэтому на самом деле вам нужно "пройтись по ссылкам" всех зависимостей, пока вы не составите полное отображение того, что требуется. Где-то в этом отображении вы можете провести грань между тем, что вам нужно для развертывания, и тем, на что может положиться операционная система или другая среда выполнения. (IMO для VB6, эта линия должна быть проведена довольно свободно).

Вы можете подумать, что все это делает задачу очень трудной или утомительной - я полностью согласен.:)

Источник

Вы можете использовать http://dependencywalker.com/, чтобы найти, от какой DLL зависит ваша программа.

Но OCX не так легко найти, потому что он загружается во время выполнения на основе зависимостей приложения и зарегистрированных компонентов через реестр Windows. Но вы уже должны знать, на какие компоненты OCX ссылается ваше приложение - из " Инструменты"> "Ссылки" и из всех мест, которые вы называете CreateObject,

Источник
Другие вопросы по тегам