Развертывание dll-библиотек Delphi ISAPI, скомпилированных с пакетами среды выполнения

У меня есть приложение ISAPI, написанное на Delphi. Приложение скомпилировано с пакетами времени выполнения. По сути, все связанные bpls должны быть развернуты в каталог с включенным ISAPI, чтобы заставить работать ISAPI dll. Однако при вызове ISAPI dll я всегда сталкиваюсь с ошибками.

Если моя DLL-библиотека ISAPI не компилируется с пакетами времени выполнения, она работает нормально.

Пакеты времени выполнения должны быть причиной проблем. Единственное решение, которое у меня есть, - это добавить путь к пакетам времени выполнения в переменную системной среды:% path% и перезагрузить компьютер.

Есть ли другое решение, не изменяя переменную окружения?

Я использую Windows 7, IIS 7 и Delphi 2010.


delphi isapi
person Chau Chee Yang    schedule 05.11.2009    source источник
comment
Есть ли конкретная причина, по которой вы строите с использованием пакетов среды выполнения?   -  person skamradt    schedule 05.11.2009
comment
да. Причин много. Раньше я был фанатом одного файла. Я отказался от этой стратегии развертывания. С пакетами времени выполнения я могу иметь более модульное и логическое представление всей архитектуры моего приложения. Кроме того, развертывание с пакетами времени выполнения позволяет нам загружать только те пакеты, которые необходимы во время выполнения для экономии ресурсов.   -  person Chau Chee Yang    schedule 06.11.2009
comment
У меня для вас новость, вы не экономите много ресурсов. ISAPI.dll загружается в оперативную память только один раз. В наши дни на серверах есть гигабайты оперативной памяти, поэтому экономия пары мегабайт не имеет значения. Плюс тот факт, что если кто-то удалит один из ваших файлов bpl, ваша DLL выйдет из строя.   -  person Dan S    schedule 06.11.2009
comment
Если кто-то сможет удалить один из моих файлов bpl, возможно, 90% других моих функций все еще будут работать. Если я разверну только одну DLL-библиотеку ISAPI, все приложение больше не будет работать. Меня больше всего беспокоит не проблема ресурсов, а разработка и развертывание пакетов среды выполнения, которые делают мое приложение более структурным и модульным. Эта конструкция также делает возможными подключаемые приложения.   -  person Chau Chee Yang    schedule 06.11.2009
comment
Стратегия подключаемых приложений имеет смысл для программы Windows, но не для ISAPI. Каждый запрос должен быть серверным без состояния для масштабирования, а каждый запрос - атомарным. Добавление еще одной DLL в микс не должно быть проблемой.   -  person skamradt    schedule 06.11.2009
comment
Я не совсем согласен с этим. Даже приложения ISAPI могут полностью насладиться подключаемым дизайном. Предположим, я разрабатываю подключаемые приложения ISAPI. Пользователь может отправить такой запрос: localhost / myapps.dll / command1. В этом случае myapps.dll выполнит command1. Команда command1 может быть подключаемым модулем в другом файле .bpl или .dll. Позже пользователь может создать другой подключаемый модуль (command2) и зарегистрироваться в модуле isapi, и теперь приложения могут обрабатывать новую команду: localhost / myapps.dll / command2. Разве это не имеет смысла?   -  person Chau Chee Yang    schedule 07.11.2009
comment
сделать мое приложение более структурным и модульным. - Я здесь через 1,5 года, но не могу не отметить, что, поскольку вы блокируете свой код в модулях, которые не видны другим разработчикам и могут иметь проблемы с интеграцией и развертыванием, вы запутываете, не делая вещи модульными и структурный. Для этого нужно написать хороший «структурированный модульный» код, а не разбивать его на исполняемые пакеты.   -  person Vector    schedule 01.09.2011

Ответы (3)


arrow_upward
1
arrow_downward

В случае, когда ISAPI DLL и исполняемые bpl находятся в одном каталоге, проверьте права доступа к файлам в вашей ISAPI DLL и исполняемых файлах .bpl и убедитесь, что у гостевой учетной записи Интернета есть доступ на чтение и выполнение к ним.

person Ben Ziegler    schedule 05.11.2009

arrow_upward
0
arrow_downward

Вы пробовали помещать файлы .bpl в каталог, где находится dll ISAPI?

Если это не сработает, создайте установщик для вашего ISAPI, и этот установщик должен скопировать все необходимые файлы .bpl в системный каталог Windows (вы можете получить его с помощью функции GetSystemDirectory() API, обычно это <WindowsDir>\system32). Для InnoSetup это {sys} место назначения файла.

person Michał Niklas    schedule 05.11.2009
comment
да. Файлы .bpl помещаются в ту же папку, что и библиотеки DLL ISAPI, и это не работает. Я не хочу помещать .bpls в папку ‹WindowsDir› \ system32, хотя это работает. - person Chau Chee Yang; 05.11.2009
comment
Попробуйте поместить их в каталог bin IIS. - person M Schenkel; 05.11.2009
comment
Обычно мне проще и надежнее создать одну большую exe / dll, а затем использовать и развернуть множество .bpls. Моя сборка серверного приложения с .bpls с использованием Delphi 4 вылетела после нескольких часов работы, в то время как она может работать неделями, если я построю ее отдельно. С .bpls он вылетал из-за некоторых странных нарушений доступа. ISAPI загружается один раз, поэтому, IMHO, его размер не имеет большого значения. - person Michał Niklas; 06.11.2009

arrow_upward
0
arrow_downward

Файлы BPL ДОЛЖНЫ находиться в системном пути машины ИЛИ в каталоге исполняемого файла (который в данном случае, как я полагаю, является svchost.exe?). А теперь самое интересное. При запуске каждого приложения создается моментальный снимок среды. Если вы добавите в путь, вам придется перезагрузить компьютер, чтобы он стал активным, ИЛИ перезапустить приложение (что в этом случае включает перезапуск ОС).

person skamradt    schedule 05.11.2009
comment
Это плохие новости и плохая стратегия развертывания. На рынке должно быть больше развертываний ISAPI. Просто интересно, как они это решают. - person Chau Chee Yang; 06.11.2009