Units in bpl auslagern und als Package in Exe/Dll einbinden

[dummzeuch]

Nur, um sicherzustellen, dass ich das richtig verstehe: Es geht um ein relativ einfaches Rahmenprogramm, welches Funktionalität mittels verschiedener Plugins als DLL anbietet? Und dieses System existiert so bereits?

Solange da die DLLs sich nicht gegenseitig aufrufen sondern nur ein vorgegebenes (prozedurales?) Interface für das Hauptprogramm zur Verfügung stellen, kann Dein Vorhaben durchaus sinnvoll sein, denn es spart für jede DLL alles das, was in den Standard-Packages zur Verfügung steht. Auch das Hauptprogramm kann dadurch kleiner werden.

Aber ich würde es bei den Standard-Packages für RTL und VCL, plus evtl. von wenigen Fremdkomponenten belassen. Sobald Du anfängst, eigenen Code in Packages zu verlagern, wird es komplex und lohnt in der Regel auch nicht.

Wichtig ist eine feste, dokumentierte Schnittstelle und eine Versionierung der DLLs, aber das sollte es für ein solches Programm bereits sowieso geben, unabhängig davon, ob Packages verwendet werden oder nicht.

[himitsu]

Nja, grundsätzlich spricht nichts dagegen, Packages anstatt DLLs zu verwenden.
Dynamisch laden lassen auch sie sich

LoadLibrary
LoadLibraryEx
SafeLoadLibrary
FreeLibrary

LoadPackage
UnloadPackage

und zusätzlich hat man den Vorteil erstmal ohne ShareMem rumzuspielen und auch stärker gemeinsamten Code, Klassen, usw. verwenden zu können.
OK, "DLLs" aus fremden Programmiersprachen fallen dann außen vor.
Und bei RuntimePackages muß man unbedingt aufpassen, dass die EXE, DLLs und BPLs in der selben Delphi-Version, Unterversion und selten sogar mit dem selben Patch kompiliert sein müssen.

Hier bietet es sich inzwischen an, mit dem automatischen Suffix zu arbeiten. (LibSuffix AUTO, siehe Projektoptionen > Beschreibung)
http://docwiki.embarcadero.com/RADSt...jects_(Delphi)


Alternativ kann man natürlich auch klassisch mit COM-Interfaces arbeiten,
sowie ganz einfache "Funktionen" in DLLs aufrufen,
oder Dergleichen.



Ja, praktisch ist es also auch möglich Erweiterungen in der Delphi-IDE zu nutzen, ohne dass beim (de)installieren die IDE beendet und neu gestartet werden muß. :freak:

[Commander Tom]

TMSSoftware bietet dazu auch etwas an: https://www.tmssoftware.com/site/tms...framework.asp#

Ob das allerdings passend sein könnte, kann ich nicht beurteilen.

[hschmid67]

Habe jetzt mal versucht nach Eurem Rat, die Module und das Hauptprogramm ohne Packages zu kompilieren. Leider klappt das, vermutlich wegen der verwendeten Komponenten, gar nicht. Ich denke, wenn ich mich recht erinnere, dass das an dem verwendeten TdxBarManager von DevExpress liegt. Muss ich aber noch testen.

Es gibt einen Toolbar im Hauptprogramm und dann jeweils auch wieder welche in den einzelnen Modulen, die als dll eingebunden werden und dort in einem Panel das jeweilige Modulfenster anzeigen. Ich glaube, mehrere BarManager vertragen sich nicht. Wie gesagt, muss ich noch testen, aber aktuell wird das Modul-Formular nicht im Panel angezeigt - und es erscheint eine leider kryptische Fehlermeldung. Ich geb Bescheid, woran es wirklich liegt, wenn ich die Zeit habe, das in Ruhe zu testen.

Ich bin übrigens gerade dran, eine Wiki-Seite für das Programm zu erstellen. Hier mal die url, auch wenn es noch lange nicht "fertig" ist. So kann man sich schon ein wenig vorstellen, wie das Programm aussieht und was es tut :-)

Insights

Viele Grüße
Harald

[himitsu]

Objekte/Klassen dürften NIEMALS über DLL-Grenzen hinweg genutzt werden. (ohne Packages)

ohne ShareMem hat jeder seinen eigenen Speichermanager
* in einem Modul (EXE/DLL) reservierter Speicher kann nicht in einem anderen Modul verändert werden
* * die Reservierung des Speichers ... der Inhalt ist was Anderes
* * z.B. die Länge eines Strings ändern, bzw. den String einer anderen Variable/Parameter zuweisen (wenn es passieren kann, dass ein String dabei freigegeben wird)

ohne Packages hat jedes Modul seine eigene Deklaration von Typen und ihrer Methoden, sowie eine komplett eigene TypeInfo/RTTI
* selbst wenn man denkt es sei identisch, ist das NIEMALs sicher
* durch Optimierung kann der Kompiler/Linker optimieren und z.B. "ungenutzte" Felder in der Klasse "weglassen"
* ist das in beiden Modulen unterschiedlich, dann denkst das eine Modul an Adresse+5 wäre das Feld, aber das Andere Modul denkt dort wäre etwas Anderes


Bei Nutzung von Interfaces sieht das Anders aus.
* hier muß man zwar drauf achten, dass alle Seiten die selbe gleiche Definition besitzen,
* aber intern wird jeder Methodenaufruf an das Modul weitergeleitet, wo das Interface/Object erstellt wurde (Create)

[johndoe049]

Auch wenn es vielleicht Off Topic erscheint, aber nur zum Verständnis gefragt:


Wenn ich das richtig verstehe ist die Planung, dass die Kunden, je nach Lizenz, nur einige oder alle .dll Dateien zum Hauptprogramm bekommen?


Was für ein Prüf Protokoll willst du dafür erstellen?

Ich weiss zwar nicht, wie das bei kaufmännischer Software ist, aber bei uns im Steuerungsbereich müsste man alle möglichen Kombinationen an Hauptprogramm und .dll bei jeder Änderung auf Seiteneffekte, Kompatibilität, Eingriffsmöglichkeiten, etc. prüfen. Durch die EU Cyber Richtlinie, die ja jetzt unter anderem auch für Fahrstuhlsteuerungen, Maschinensteuerungen und Fahrzeugsteuerungen gilt, ist das ein erheblicher Test- und Dokumentationsaufwand. Das ist unheimlich Kostenintensiv. Daher machen die meisten im Steuerungsbereich die Einschränkungen über Funktionsfreischaltung im Lizenzcode oder Lizenzdongle und Updates über Binäre Delta Updates.

Ist das bei kaufmännischer Software nicht so relementiert? Kann man da wirklich "machen was man will, hauptsache es funktioniert"? Wie macht Ihr da das Qualitätsmanagement und die Prüfdokumentation oder ist das auch nicht notwendig?