Распространение пакета времени разработки со сторонними элементами пользовательского интерфейса

Теперь, когда я больше узнаю об аспектах разработки компонентов во время проектирования, у меня есть то, что может оказаться парой «плагинов» IDE, нацеленных на Delphi 2007 (+ другие, если они совместимы).

Формы / пользовательский интерфейс для них, в идеале, будут использовать некоторые из сторонних компонентов, которые я использую регулярно. Предполагая, что лицензирование позволяет распространять эти компоненты для плагина IDE и т. Д., Что мне нужно сделать по-другому для подготовки пакета распространения по сравнению с тем, что можно было бы сделать с пакетом с «полным исходным кодом»?

(Надеюсь, этот вопрос имеет смысл. Пожалуйста, будьте добры и задавайте вопросы, если нет).


ide delphi custom-component packages bpl
person Jamo    schedule 22.04.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Вам необходимо распространять BPL, скомпилированный для каждой версии Delphi, которую вы поддерживаете (Версия + Обновление), а затем распространять только BPL. Настройте виртуальную машину для тестирования. BPL - это специальная DLL, поэтому вы распространяете только двоичный файл, который должен работать с вашими лицензиями.

Распространение .PAS или .DCU, скорее всего, нарушит лицензионное соглашение.

person Jim McKeeth    schedule 22.04.2009

arrow_upward
2
arrow_downward

Вы, вероятно, обнаружите, что это вызывает всевозможные проблемы.

GExperts делает иначе. Это DLL, которая статически связана с некоторыми сторонними элементами управления и ссылается только на собственные пакеты времени выполнения Delphi. Это не может вызвать никаких конфликтов с другими пакетами, потому что статически связанные модули не видны для IDE. Это также означает, что GExperts не нужно распространять какие-либо пакеты времени выполнения.

person dummzeuch    schedule 22.04.2009

arrow_upward
1
arrow_downward

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

Компоненты, которые вы используете, уже должны были быть предоставлены их поставщиком в рабочем пакете. Поместите этот пакет в список «требуемых» вашего пакета времени разработки. Распространяйте только файл .bpl; Я думаю, вы можете установить его в тот же каталог, что и ваш пакет времени разработки.

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

person Rob Kennedy    schedule 22.04.2009
comment
К сожалению, это не решает проблему, связанную с тем, что издатель компонента может выпустить обновленный .bpl, который содержит те же имена модулей, но несовместим со старым .bpl. В этом случае Delphi откажется загружать компоненты или плагин из-за дублирования имен модулей или отсутствия точек входа. - person dummzeuch; 22.04.2009
comment
Риск того, что поставщик выпустит новый BPL, несовместимый с предыдущими версиями, присутствует всегда, но это также вина поставщика, который нарушил работу существующих потребителей BPL путем удаления чего-либо из опубликованного интерфейса. - person Rob Kennedy; 22.04.2009