Eigene Komponente weitergeben

[sko1]

Hallo,

ich habe eine Komponente entwickelt, welche eine zugekaufte Library (reiner Source ohne sichtbare Komponenten) nutzt.
Diese ist natürlich auf meinem Rechner installiert, die Komponente kann bei mir installiert und genutzt werden.

Was passiert aber auf einen Rechner eines Kollegen, muss für die Installation des Packages bei dem dann auch diese Library vorher installiert werden?

Ich möchte ungern nach Übergabe der Komponente "auf den Bauch fallen" weil sie nicht installierbar ist...

Ciao
Stefan

Nachtrag:
Ich denke inzwischen darüber nach, die in der Library verwendeten Funktionalitäten in eine DLL auszulagern und diese mitzugeben, damit wäre ja die Problematik der auf dem Zielrechner nicht vorhandenen Library umgangen oder liege ich da falsch?

[jaenicke]

Das ist ja auch eine Lizenzfrage. Wenn die Fremdkomponente nur für dich lizenziert ist, darf sie jemand anderes ja auch nicht zur Entwicklung nutzen, das heißt du kannst weder den Quelltext noch die kompilierten Units mitliefern. Eins von beidem wird aber benötigt werden.

Sollte das so sein, bleibt tatsächlich nur auf eine kompilierte Variante wie eine DLL auszuweichen, da du die dann ja weitergeben darfst.

Wir machen das bei uns so, dass wir Fremdquelltexte in Packages zusammenfassen, die dann auch per Buildskript kompiliert werden können. Jeder Entwickler kann das dann so auschecken und auch alles kompilieren, nutzen usw. ohne selbst viel manuell machen zu müssen. Dadurch ist auch jeder auf dem gleichen Stand.
Wir kaufen natürlich auch entsprechende Team- oder Mehrplatzlizenzen, je nachdem was verfügbar ist.

Ich fände es aber auch hochproblematisch, wenn bestimmte Teile des Quelltextes (in dem Fall die Fremdkomponente) nur an einem Entwicklerrechner verfügbar wären und woanders z.B. nur die kompilierten DLLs oder DCUs vorhanden wären. Dann könnte ja niemand anderes Modifikationen vornehmen. (Und manchmal muss das ja auch an den Fremdquelltexten passieren.)
Dass normalerweise niemand anderes das editieren muss oder darf, je nach Organisation, ist eine andere Sache, aber die Möglichkeit zu haben fände ich sehr wichtig.

// EDIT:
Ach ja, debuggen wäre natürlich auch einfacher, wenn man direkt Zugriff auf alle Quelltexte hat und nicht den Entwickler einer zusätzlichen DLL, also dich, zum Debuggen fragen müsste.

[sko1]

Danke für Deine Infos!

Dann werde ich um die DLL nicht herumkommen, was aber eigentlich (außer dass ich dann für Fehlersuche zuständig bin) den Vorteil hat, bei Korrekturen nicht das gesamte Programmpaket neu erstellen zu müssen sondern einfach die DLL austauschen, das macht es später bei den Kunden einfacher die nicht 600MB Komplettpaket downloaden müssen...

Wenn andere Entwickler dann ggf. auch mal was an der DLL machen müssen, dann müssen sie halt die (sehr umfangreiche) Library halt auch installieren.

Was mir aber dabei noch auffällt:

Ich leite meine Komponente vom TWPPDFPrinter von WPTools ab. Ich habe Delphi 10.1 (Update 2).
Alle anderen Entwickler haben noch XE5 bzw. XE6 und da die WPTools für ihre Version installiert.
Kann es da zu Problemen kommen wenn die meine Komponente kompilieren / installieren wollen?

Ciao
Stefan

[TBx]

Zitat:

Zitat von sko1 (Beitrag 1378551)

Ich habe Delphi 10.1 (Update 2).
Alle anderen Entwickler haben noch XE5 bzw. XE6 ...
Kann es da zu Problemen kommen wenn die meine Komponente kompilieren / installieren wollen?

Sie können Deine Komponente nur benutzen, wenn sie diese im Quellcode erhalten und selber kompilieren. Die BPL-Formate sind nicht binär-kompatibel!

[jaenicke]

Zitat:

Zitat von sko1 (Beitrag 1378551)

Alle anderen Entwickler haben noch XE5 bzw. XE6 und da die WPTools für ihre Version installiert.
Kann es da zu Problemen kommen wenn die meine Komponente kompilieren / installieren wollen?

Sofern es sich um die gleiche Version handelt und lediglich das Package für die jeweilige Delphiversion verwendet wird, sollte das kein Problem sein.

Mit ist aber nicht so ganz klar wie du das mit der DLL eigentlich meinst. Denn eine Komponente kannst du ja nicht als DLL verteilen, sondern nur Interfaces usw. aus der DLL heraus veröffentlichen. Und dann ist es doch völlig egal wovon die nur in der DLL verwendete Komponente abgeleitet ist.

[sko1]

Die Library, von der ich spreche, ist die Foxit Debenu PDF Library, die ich nutze um spezielle PDF mit eingebettetem XML (ZUGFeRD) zu erzeugen.

Dieses Foxit ist eben nur auf meinem Rechner, deswegen die DLL.

Es wird also erst das PDF-A mit meinem "erweiterten WPTools Printer" erzeugt, welches dann von der DLL entsprechend bearbeitet und wieder gespeichert wird.

Ciao
Stefan

[himitsu]

Wird die Fremdkomponente nur intern genutzt:

Das Einkompilierte, bzw. die Laufzeitpackages von dieser Fremdkomponenten darfst du mitgeben.



Du kannst dann eben nur die lauffähigen Binaries (BPL und DCP) deiner Komponente ausliefern, inkl. der BPLs (ohne DCP, DCU, PAS, ...) der Fremdkomponente,
aber da mußt du eben für jede Version die Binaries erstellen.
Denn XE 10.2 nimmt eben nur die BPLs welche für 10.2 kompilert wurden, eben so die anderen Delphiversionen.

Natürlich kannst du dennoch deine Quellcodes als OpenSource bereitstellen, aber kompilieren kann sie dann eben nur der, welcher ebenfalls die von dir verwendete Fremdkomponente bei sich installiert hat.




Oder du legst direkt als Abhängigkeit fest, dass der Nutzer deiner Komponente eben auch diese andere Komponente benötigt ...

[jaenicke]

Zitat:

Zitat von sko1 (Beitrag 1378560)

Es wird also erst das PDF-A mit meinem "erweiterten WPTools Printer" erzeugt, welches dann von der DLL entsprechend bearbeitet und wieder gespeichert wird.

Ah, verstehe. Dann sollte das so passen, ja.