コンポーネント開発の設計時の側面について学んできたので、Delphi 2007をターゲットにしたIDEプラグインをいくつか紹介します（+その他の場合は互換性があります）。サードパーティ製のUI要素を含むデザイン時パッケージの配布
これらのフォーム/ UIは、理想的には、私が定期的に使用する第三者コンポーネントの一部を利用します。 IDEプラグインなどでこれらのコンポーネントを配布するライセンスがあれば、「完全なソース」を持つパッケージの場合と比べて、配布パッケージを準備するために何をする必要がありますか？
（この質問は意味があると思いますが、質問してください）
（Version + Update）をサポートするDelphiの各バージョン用にコンパイルされたBPLを配布してから、BPLのみを配布する必要があります。それをテストするために仮想マシンをセットアップします.BPLは特別なDLLであるため、ライセンスで動作するバイナリのみを配布しています。
.PASまたは.DCUを配布することは、おそらくライセンス契約に違反します。
これらのコンポーネントをデザイン時パッケージに配布しないでください。顧客が自分のプロジェクトで同じコンポーネントを使用したいと思っている場合、それはあなたとあなたの顧客の頭痛を引き起こします。それらのコンポーネントのユニットをデザインタイムパッケージに入れると、一度に1つのユニットのコピーしかロードできないため、顧客はツールパレットにインストールされたコンポーネントのコピーを所有することができません。
使用しているコンポーネントは、すでにベンダーのランタイムパッケージに入っているはずです。 そのパッケージをデザイン時パッケージの「必要な」リストに入れます。 .bplファイルのみを配布します。私はあなたがあなたのデザインタイムパッケージと同じディレクトリにインストールできると思います。
ランタイムパッケージは、ベンダーのデザインタイムパッケージの要件となります。これは、お客様がIDEにインストールしたパッケージです。
おそらく、これはあらゆる種類の問題を引き起こすでしょう。
GExpertsはそれとは異なります。静的にサードパーティ製のコントロールにリンクし、Delphi独自のランタイムパッケージのみを参照するDLLです。これは、静的にリンクされたユニットがIDEから見えないため、他のパッケージと競合することはありません。また、GExpertsはランタイムパッケージを配布する必要はありません。
これは残念ながら、コンポーネントのパブリッシャが同じユニット名を含む更新済み.bplをリリースする可能性はありますが、古い.bplとは互換性がないという問題は解決しません。その場合、ユニット名が重複しているかエントリポイントがないため、Delphiはコンポーネントまたはプラグインの読み込みを拒否します。 – dummzeuch
ベンダーが以前のリリースと互換性のない新しいBPLをリリースするリスクは常に存在しますが、公開されたインタフェースから何かを削除することによってBPLの既存のコンシューマーを破ることもベンダーの責任です。 –