LoadPackage .bpl von Netzlaufwerk laden

[omnibrain]

"Für ein Plugin-System habe ich heuer zum ersten Mal ein Package geschrieben.
Das Package soll dynamisch zur Laufzeit mit LoadPackage geladen werden. Die Procedures hole ich mit dann über "GetProcAddress()".
Der Pfad von dem das Package geladen wird bestimme ich dynamisch. Bei mir auf dem Entwicklungssystem klappt auch alles, das Package wird geladen, alles funktioniert.

Nur auf den Testsystemen klappt es nicht. Dort wird das BPL von einem Netzlaufwerk geladen. Der Pfad wird (wie ich an Hand der Fehlermeldung sehen kann) korrekt bestimmt.
Die Fehlermeldung ist:
"Package L:\Packages\Player\lvideoplayer.bpl kann nicht geladen werden. Das angegebene Modul wurde nicht gefunden"

Betriebssystem ist Windows 11 und ich setze Delphi 11.2 ein.

Können Packages vielleicht nicht von Netzlaufwerken geladen werden? Am gleichen Ort liegen auch DLLs die von fertigen Komponenten (da habe ich mit dem Laden nichts zu tun) in anderen Teilen des Programms benutzt werden. Das klappt problemlos.

[dummzeuch]

Zitat:

Zitat von omnibrain (Beitrag 1515240)

Nur auf den Testsystemen klappt es nicht. Dort wird das BPL von einem Netzlaufwerk geladen. Der Pfad wird (wie ich an Hand der Fehlermeldung sehen kann) korrekt bestimmt.
Die Fehlermeldung ist:
"Package L:\Packages\Player\lvideoplayer.bpl kann nicht geladen werden. Das angegebene Modul wurde nicht gefunden"

Vermutlich benötigt das Package weitere DLLs / Packages und die Fehlermeldung bezieht sich auf diese, nicht auf das Package selbst.

Generell gilt allerdings:
Wenn Du ein Plugin-System mit Packages in Deinem Programm verwenden willst, muss für Dein Projekt "Build with Packages" eingeschaltet sein und zumindest die Standard RTL- und vermutlich auch VCL-Packages in der Liste stehen (alle, die die Plugin-Packages benutzen sollen). Und diese Packages müssen dann auch im Pfad liegen.

[omnibrain]

Zitat:

Zitat von dummzeuch (Beitrag 1515243)

Generell gilt allerdings:
Wenn Du ein Plugin-System mit Packages in Deinem Programm verwenden willst, muss für Dein Projekt "Build with Packages" eingeschaltet sein und zumindest die Standard RTL- und vermutlich auch VCL-Packages in der Liste stehen (alle, die die Plugin-Packages benutzen sollen). Und diese Packages müssen dann auch im Pfad liegen.

Danke. Das wird es dann sein. Auf meinem Entwicklungssystem sind die natürlich vorhanden. Auf dem anderen System nicht.

Ich hatte die Hoffnung, dass ich so schön einfach bei Bedarf zusätzliche/andere BPLs bereitstellen kann. Aber ich möchte natürlich nicht noch dutzende anderer Packages mit ausliefern müssen. In dem Fall ist es vermutlich besser, wenn ich versuche das ganze in eine DLL zu gießen. Das wird halt bei den Datentypen nicht ganz so bequem. Andererseits könnte ich dann für zukünftige Plugins bei Bedarf auch andere Sprachen nutzen.

[dummzeuch]

Kommt mir bekannt vor. Genau deshalb habe ich schon mehrfach davon abgesehen, überhaupt ein Plugin-System zu verwenden. Es war dann hinterher deutlich einfacher, ein monolitisches Executable incl. des "Plugin"-Codes zu haben und diese Funktionalität per Lizenz freizuschalten.

[jaenicke]

Zitat:

Zitat von dummzeuch (Beitrag 1515246)

Kommt mir bekannt vor. Genau deshalb habe ich schon mehrfach davon abgesehen, überhaupt ein Plugin-System zu verwenden. Es war dann hinterher deutlich einfacher, ein monolitisches Executable incl. des "Plugin"-Codes zu haben

Das sehe ich anders. Ein gut gemachtes interface-basiertes Pluginsystem auf DLL-Basis funktioniert sehr gut, lässt sich auch problemlos mit Generics nutzen und kann auch DLLs nutzen, die in anderen Sprachen als Delphi geschrieben sind.

Ich kann auf diese Weise z.B. in der Hostanwendung schreiben:

Delphi-Quellcode:

if TDllInterface.TryGet<IExample>('Ein Parameter', Example) then
  Example.Execute;

Die DLL stellt dabei das IExample Interface bereit.

[omnibrain]

Für dieses spezielle Beispiel (es sollen praktisch nur "plugbare" Videoplayer mit unterschiedlichen Features/Bibliotheken, etc. werden) mache ich es jetzt viel einfacher: Eigenständige Programme die per ShellExecute parametrisiert gestartet werden. Die paar Informationen die ich übergeben muss passen in die Parameter.
Falls ich doch kommunizieren muss (unwahrscheinlich), dann sende ich eben Messages, oder mache falls nötig IPC.

Wenigstens habe ich ordentlich was dabei gelernt und "den Rush" gespürt.

[himitsu]

Erstmal,
der ProcessExplorer hilft, zu zeigen, was wirklich (nicht) geladen werden kann.

und eventuell hilft
AddDllDirectory
RemoveDllDirectory
SetDllDirectory
SetDefaultDllDirectories
https://learn.microsoft.com/en-us/wi...y-search-order

[omnibrain]

Zitat:

Zitat von himitsu (Beitrag 1515270)

Erstmal,
der ProcessExplorer hilft, zu zeigen, was wirklich (nicht) geladen werden kann.

und eventuell hilft
AddDllDirectory
RemoveDllDirectory
SetDllDirectory
SetDefaultDllDirectories
https://learn.microsoft.com/en-us/wi...y-search-order

Danke, das meiste ist mir hier klar. Ich hatte eher die Befürchtung, dass es einen (Sicherheits-)Mechanismus gibt, der verhindert, dass BPL von Netzlaufwerken geladen werden. Man weiß ja nie...
Das Problem war tatsächlich, das von Thomas beschriebene, dass ich noch mehr Packages mit ausliefern müsste.
Aber an der Stelle fahre ich jetzt wirklich mit einer komplett separaten .exe besser.

[himitsu]

Nee, hätten wir gemerkt, da wir auch mit Packages arbeiten und beim Kunden das auf NetShares liegt.

Es gibt nur ein Problem, wenn das im Rootverzeichnis des Shares (z.B. SMB) liegt, weil Dank einem Bug im Windows dann das Laden eventuell extrem verlangsamt wird ... ziemlich genau 30 Sekunden hängen/warten, je BPL/DLL/EXE ... bei 80 Eigenen und über 300 FremdPackages (v.a. DevExpress), kann das Starten dann "richtig" lange dauern.

https://www.delphipraxis.net/207151-...s-sandbox.html
Da drin kann man wunderbar testen, ob etwas fehlt. (extrem abgespecktes Windows, ohne Sonstwas)