Benutzerdefinierte Komponente Abhängigkeit Hölle

Question

Ich versuche, ein Paket für eine benutzerdefinierte Komponente, die ich gemacht habe, zu machen. Es basiert auf mehreren Bibliotheken, einschließlich Graphics32, GraphicEx und CCR.Exif.

Ich habe ein Paket Projekt, das Gerät einschließlich der Prozedur Register schrieb, fügte einige zusätzliche Referenzen Delphi mich zum erfordert Abschnitt Benachrichtigung (einschließlich dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg. dcp, xmlrtl.dcp und dclGraphicEx140.dcp) und viele Einheiten zum Abschnitt hinzugefügt hinzugefügt, um Warnungen zu vermeiden, die implizit auftreten. Das Projekt wird kompiliert und kann problemlos auf meiner eigenen Maschine installiert und verwendet werden. Wenn ich es jedoch auf einem anderen Computer installieren möchte, beginnen die Probleme. Am Ende musste ich über alle DCUs von allen 3rd-Party-Komponenten, die ich verwendete, plus DCP und BPL von GraphicEx kopieren, die ich sogar installieren musste.

Viele Dateien zu liefern ist ein Mist, aber überwindbar, aber auch andere Pakete zu installieren, ist ein Nein. Ich könnte dieses DCP und BPL loswerden, indem ich noch mehr Einheiten in den enthält Abschnitt, aber das führte zu Fehlermeldungen auf meinem eigenen Computer, wo GraphicEx tatsächlich installiert ist. Das ist verwirrend für mich, denn mit Graphics32 passiert nichts dergleichen ...

Wie kann ich meine Verteilung auf ein Minimum beschränken und solche Situationen vermeiden? Ich möchte, dass andere Entwickler in meinem Team das Paket verwenden können, ohne sich Gedanken darüber machen zu müssen, was ich zum Erstellen verwendet habe. Können nicht alle 3rd Party Units zu einer eigenen DCU zusammengefasst werden?

Answer 1

Zusammenfassung

Haben Delphi für eine Weile nicht benutzen, aber habe meine individuelle visuelle Kontrollen entwickeln (letzte Version, die ich Arbeit war Delphi 6).

Beim Umgang mit Paketabhängigkeiten treten zwei Probleme auf. Die eine Installation erfolgt in der Delphi-Umgebung, sodass die Steuerelemente in der Komponentenpalette sowie die Komponenteneditoren & Eigenschafteneditoren angezeigt werden.

Und ein weiteres beim Verteilen der kompilierten Pakete in Kunden Maschinen.

Es hängt auch davon ab, auf welcher Version von Delphi Sie laufen.

Design Time

Wenn ein benutzerdefiniertes Paket zu entwickeln, gibt es eine Registerkarte für Paket-Optionen, die die Zielordner angibt.

Normalerweise wird den Entwicklern in den Handbüchern gesagt, diese Textfelder leer zu lassen. Das funktioniert manchmal, manchmal nicht. Ich schreibe explizit jeden Ordnerpfad in das entsprechende Textfeld.

Es gibt einen Textfeldpfad für die Dateien ".dcp", andere für " .dcu" und so weiter.

Wenn Sie visuelle Steuerelemente und ähnliches wie Eigenschafteneditoren oder Komponenteneditoren haben, ist es besser, den Code in 2 Pakete zu teilen ("Runtime" & "Designtime").

Ich lege die Delphi (Pakete) Projekte normalerweise außerhalb des Delphi Installationsordners.

Laufzeit

Normalerweise ist der schnelle Weg, um die "* .bpl" ".DCP-" Dateien im Windows (32)/Systemordner oder ähnlichen "DLL" Windows-Ordner zu setzen.

---

Pakete Ordnerstruktur Quellcode Vorschlag

Paketverwaltung kann schwierig sein. Ich weiß nicht, wie viel sich der Installationsprozess mit Embarcadero und den neueren Versionen von Delphi geändert hat. Das folgende Diagramm zeigt ein Beispiel für die Organisation des Quellcodes. Ich hoffe es hilft.

[-]--+--c: 
.....| 
.....+--[-]--+--software 
.............| 
.............+--[+]-----java 
.............| 
.............+--[+]-----php 
.............| 
.............+--[-]--+--delphi (not the delphi folder in program files) 
.....................| 
.....................+--[+]-----apps (source code for delphi programs) 
.....................| 
.....................+--[+]-----other 
.....................| 
.....................+--[-]--+--packages (all delphi packages source code here) 
.............................| 
.............................+--[+]-----lib (a single package for non visual controls, libraries) 
.............................| 
.............................+--[+]-----tools (package pair for non visual tcomponent descendants) 
.............................| 
.............................+--[+]-----json (example) 
.............................| 
.............................+--[+]-----xml (example) 
.............................| 
.............................+--[-]--+--mycontrols (folder custom visual controls) 
.............................|.......| 
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder) 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols") 
.............................|................ 
.............................+--[-]-----etc... 

---

Beifall.

Answer 2

Thijs, das kann man mit einem Paket einfach nicht machen. Der Zielentwickler benötigt fast alles, was Sie dem Paket hinzugefügt haben. Aber es gibt eine alternative Möglichkeit, das zu tun, was Sie wollen: Erstellen Sie eine DLL mit allen Komponenten/Bibliotheken, die Sie in Ihrer eigenen Komponente verwenden, und umschließen Sie alle diese externen Komponenten/Bibliotheken in Code, den Sie aus der DLL exportieren. Erstellen Sie dann Ihre Komponente, ohne die externen Komponenten direkt zu verwenden, sondern die von Ihnen erstellte DLL. Sie können in Ihrer Komponente keine Einheit der anderen externen Komponenten/Bibliotheken verwenden. Sie müssen eine neue Einheit mit allen Datentypen und der erforderlichen Deklaration für alles, was Sie aus Ihrer DLL exportieren, erstellen. All dies funktioniert perfekt, wird aber für eine große Anzahl von externen Komponenten oder Bibliotheken schnell sehr komplex.

Answer 3

Was Sie erlebt haben, ist eine gewöhnliche Sache für diejenigen, die Komponenten schreiben. Die Verteilung ist immer so. Pakete tragen keine anderen Pakete, sie verweisen auf sie. Es liegt in ihrer Natur.

Um eine solche Situation zu überwinden, behandle ich meine Komponenten immer so, wie sie es wären, wenn sie ein Produkt zum Verkauf wären: Ich baue einen Setup-Assistenten, der alles verteilt und registriert, was das Paket benötigt.

In meinem Fall funktioniert InnoSetup sehr gut (http://www.jrsoftware.org/isinfo.php).

Answer 4

Ich denke, AlexSC hat die beste Antwort, aber ich denke, es könnte eine Alternative sein, wenn Sie absolut eine benutzerdefinierte Komponente haben müssen, die keine Abhängigkeiten hat.

Ich stieß ein wenig auf die Dependency-Frustrationen in Delphi und versuchte eine interne Komponente für unsere Entwickler zu erstellen. Mein Vorschlag:

1. Deinstallieren Sie alle Abhängigkeiten Ihre Komponente verwendet

2. In Ihrem Komponentenpaket, entfernen Sie die oben dcp aus dem Abschnitt von Ihrem Paket erfordert.

3. Kopieren Sie die Quelldateien Ihrer Abhängigkeiten zu Ihren Komponenten

Wenn Sie die Komponente zu verteilen, werden Sie es mit dem Code des erforderlichen dependecies

Sie werden laufen distibute müssen in Probleme, wenn Sie die Abhängigkeiten getrennt verwenden möchten, da Delphi Ihnen nicht erlaubt, doppelte Einheitennamen in installierten Paketen zu haben.

Der Grund, warum Sie DCUs nicht verwenden möchten, ist die Tatsache, dass die DCUs für eine bestimmte Plattform und einen Compiler kompiliert werden. Wenn Sie also nicht sicher sind, dass sich alle Devolpers auf derselben Plattform-Anzeige befinden und dieselbe Version von Delphi verwenden, muss der Abhängigkeitscode neu kompiliert werden.

Wieder hat AlexSC die beste Antwort und InnoStudio ist ein großartiges kleines Werkzeug.