#dll #c builder #c builder-10-seattle #procmon
#dll #c builder #c builder-10-Сиэтл #procmon
Вопрос:
У меня есть приложение VCL, созданное в C Builder 10.0 в Сиэтле. Он использует Axis Media Control в форме для отображения видео, поэтому он загружает AxisMediaControl.dll файл при запуске.
В прошлом у меня это было развернуто на 32-разрядной целевой машине, где приложение находилось в C:Program FilesAppName каталоге, и AxisMediaControl.dll оно было установлено в том же месте. Все работало, как ожидалось.
Это приложение является 32-разрядным приложением, поэтому при развертывании на 64-разрядной целевой машине оно устанавливается в C:Program File (x86)AppName каталог. И снова AxisMediaControl.dll файл развертывается в каталоге приложения.
Приложение не запускается с ошибкой «Не удалось найти указанный модуль». Используя Process Monitor, я обнаружил, что программа ищет библиотеку DLL Axis в более старом Program Files каталоге вместо x86 каталога. Что может заставить приложение искать DLL в этом расположении?
Запустив тот же двоичный файл на моем компьютере разработчика, приложение загружает DLL из моего SysWOW64 каталога. Если библиотека DLL размещена там на целевой машине, она по-прежнему не может найти это местоположение. Он просматривает ТОЛЬКО более старый Program Files путь к приложению, который я не могу понять.
Я надеюсь, что кто-нибудь сможет пролить некоторый свет.
Комментарии:
1. Единственный способ, которым он может искать в старой
Program Filesпапке в 64-битной системе, — это если вы указываете ему искать там, например, если вы вручную вызываетеLoadLibrary()старый путь. Если библиотека DLL статически связана с приложением или приложение динамически загружает ее по относительному пути, тогда она должна искать DLL в пути поиска ОС , который всегда сначала просматривается в папке установки приложения.2. Я тоже так думал, Реми. Нигде в моем проекте я не вызываю LoadLibrary() или любой другой метод для загрузки dll во время выполнения. Я нашел несколько записей реестра в целевой системе, ссылающихся на этот путь и имя dll. Изменение или изменение их нарушило возможность запуска приложений. Очень странно, все еще работаю над выяснением того, как ОС ссылается на эти области реестра вместо пути поиска ОС, как вы упомянули.
3. Таким образом, ti выясняет, что при дополнительном исследовании элемент управления AMC (Axis Media) ищет путь к AxisMediaControl.dll файл, использующий идентификатор класса в реестре …{745395C8-D0E1-4227-8586- 624CA9A10A8D}. Указанный там путь затем используется для загрузки библиотеки DLL. Я хотел бы сделать это по-другому, но похоже, что Axis сделал в своем коде, поскольку пакет AMC должен быть предварительно установлен. По крайней мере, я понял, почему он загружает его с этого пути.
4. Это означает, что DLL реализует COM-объект, который требует регистрации, прежде чем его можно будет использовать. Если ваше приложение не использует манифест, который позволяет активировать COM-активацию без регистрации , вы можете ссылаться на DLL-файл напрямую, не используя реестр.