Projekt mit Runtime-Packages compilieren - BPL nicht gefunden

[Codehunter]

Wie ist das dann eigentlich, wenn Plugin-BPLs ihrerseits wieder BPLs laden wollen. Ich habe vor, meine Plugins in einem Plugin-Ordner der Anwendung zu sammeln und von dort dynamisch zu laden. Statisch gelinkte BPLs werden doch aber entweder von dem Verzeichnis geladen wo die Exe vom Hauptprogramm liegt oder aus einem der %PATH%-Verzeichnisse.

Wo suchen denn meine Plugin-BPLs dann nach ihren eigenen statisch gelinkten BPLs? Im Ordner der Hauptanwendung die das Plugin aufgerufen hat oder im Ordner, in dem das Plugin-BPL liegt?

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1274978)

Wo suchen denn meine Plugin-BPLs dann nach ihren eigenen statisch gelinkten BPLs? Im Ordner der Hauptanwendung die das Plugin aufgerufen hat oder im Ordner, in dem das Plugin-BPL liegt?

statisch gelinkte BPL sind für Windows erstmal DLLs. D.h. Du musst dein Windows bzw. MS fragen wie suchreihenfolge bezüglich der DLLs ist.

[Codehunter]

Ok, dann bastel ich mal weiter. Die Frage an sich ist ja damit beantwortet. Danke an alle die geholfen haben.

[Codehunter]

Sooo... da wäre das nächste Problemchen. Plugin auf BPL-Basis gebastelt, für Win32 kompiliert - Funktioniert. Wenn ich aber für Win64 kompiliere, dann bekomme ich unmittelbar beim "LoadPackage()" vom Debugger ein "Disconnected Session" mit folgendem Inhalt:

Code:

[2039534C]{dbkdebugide180.bpl} Debug.TDebugKernel.msgBox (Line 5931, "Debug.pas" + 30) + $0
[03F16EB3]{bordbk180.dll} Unbekannte Funktion bei DllUnregisterServer + $5037
[03F8B8A8]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $619D0
[03F8B927]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $61A4F
[03F8C36D]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $62495
[03F8C5BD]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $626E5
[03FBC3E3]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $9250B
[03F29D72]{bordbk180.dll} Unbekannte Funktion bei DllUnregisterServer + $17EF6
[03F8B8CC]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $619F4
[50455D4A]{vcl180.bpl  } Vcl.Controls.TWinControl.GetControl (Line 9131, "Vcl.Controls.pas" + 4) + $A
[5057C713]{vcl180.bpl  } Vcl.Forms.TraverseClients3 (Line 7261, "Vcl.Forms.pas" + 5) + $29
[03F8C7FC]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $62924
[03F34263]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $A38B
[505777F9]{vcl180.bpl  } Vcl.Forms.TCustomForm.WndProc (Line 4388, "Vcl.Forms.pas" + 201) + $5
[50452734]{vcl180.bpl  } Vcl.Controls.TControl.Perform (Line 7002, "Vcl.Controls.pas" + 10) + $8
[50582B07]{vcl180.bpl  } Vcl.Forms.TApplication.DispatchAction (Line 11494, "Vcl.Forms.pas" + 9) + $C
[505801E3]{vcl180.bpl  } Vcl.Forms.TApplication.WndProc (Line 9857, "Vcl.Forms.pas" + 98) + $B
[50170090]{rtl180.bpl  } System.Classes.StdWndProc (Line 16860, "System.Classes.pas" + 8) + $0
(00037995){CnWizards_DXE4.dll} [0F428995]
(000379FC){CnWizards_DXE4.dll} [0F4289FC]
(00035275){CnWizards_DXE4.dll} [0F426275]
(00037995){CnWizards_DXE4.dll} [0F428995]
(000379FC){CnWizards_DXE4.dll} [0F4289FC]
(00037AAD){CnWizards_DXE4.dll} [0F428AAD]
(000352EE){CnWizards_DXE4.dll} [0F4262EE]
[500630C0]{rtl180.bpl  } System.@FinalizeArray (Line 29800, "System.pas" + 139) + $0
[500630B0]{rtl180.bpl  } System.@FinalizeArray (Line 29788, "System.pas" + 127) + $0
[50580E8F]{vcl180.bpl  } Vcl.Forms.TApplication.ProcessMessage (Line 10290, "Vcl.Forms.pas" + 25) + $1
[50580ECA]{vcl180.bpl  } Vcl.Forms.TApplication.HandleMessage (Line 10318, "Vcl.Forms.pas" + 1) + $4
[50581205]{vcl180.bpl  } Vcl.Forms.TApplication.Run (Line 10456, "Vcl.Forms.pas" + 26) + $3

Was ich sicher sagen kann: Die zu ladende .bpl existiert, liegt zusammen mit der Host.exe im selben Verzeichnis und ist auch passend dazu als Win64-Debug kompiliert. Eine andere gleichnamige BPL bekommt er nicht zu fassen, hab sicherheitshalber alle gelöscht.

Kann jemand was mit der Meldung anfangen?

[Stevie]

Hau deine exe und bpl mal in den Dependency Walker rein, der sagt dir dann schon, welche anderen statisch gebundenen Module nicht vorhanden sind.

[Codehunter]

Danke für den Tip. Der sagt mir dass bei Win64 so ziemlich alles fehlt was nur fehlen kann. Sprich die ganzen Komponenten-BPLs. Alles was so schön in der IDE verschraubt ist.

Seltsam ist dabei nur, dass sich da die Win32- und Win64-Versionen meines Testprogramms unterschiedlich verhalten. Während meine Plugin.bpl auf Win32 außer vcl180.bpl und rtl180.bpl gar nichts weiter haben will, mokiert sich die Win64-Version so ziemlich über alles.

Getestet jeweils auf 100% "BPL-freien" Test-VMs.

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275101)

Danke für den Tip. Der sagt mir dass bei Win64 so ziemlich alles fehlt was nur fehlen kann. Sprich die ganzen Komponenten-BPLs. Alles was so schön in der IDE verschraubt ist.

Seltsam ist dabei nur, dass sich da die Win32- und Win64-Versionen meines Testprogramms unterschiedlich verhalten. Während meine Plugin.bpl auf Win32 außer vcl180.bpl und rtl180.bpl gar nichts weiter haben will, mokiert sich die Win64-Version so ziemlich über alles.

Getestet jeweils auf 100% "BPL-freien" Test-VMs.

Sicher, dass du Uwes Hinweis

Zitat:

Zitat von Uwe Raabe (Beitrag 1274972)

Zitat:

Zitat von Codehunter (Beitrag 1274969)

Also muss ich das Ganze so verstehen, dass die IDE per Default erstmal jedes erdenkliche in der IDE registrierte Package in die Liste der Laufzeit-Packages einträgt und man dann her gehen muss und die nicht benötigten wieder abwählen muss?

Genau so ist es! Bei der Installation eines Design-Packages werden die dafür benötigten Runtime-Packages in diese (interne) Liste mit aufgenommen. Diese wird dann für neue Projekte herangezogen und sollte jeweils angepasst werden. Man will ja nicht alle möglichen Runtime-Packages mitliefern, nur weil man vielleicht eine Handvoll Units daraus braucht.

auch für die 64-bit Version deines Packages durchgeführt hast? Ansonsten sorge dafür, dass die ganzen 3rd Party Komponenten Packages auch in der 64-bit Version zur Verfügung stehen.

[Codehunter]

Also in meiner IDE gibt es bei den Projekteinstellungen keine nach Win32 und Win64 getrennte Package-Auswahl. Entweder man machts für alle Plattformen oder gar nicht. Was mich aber grad richtig nervt: Die abgewählten Packages speichert Delphi nicht in den Projekteinstellungen. Sprich nach dem nächsten Öffnen des Projektes kann man die ganze Auswahl wiederholen.

Mich würde interessieren, ob man nicht eine BPL so erstellen kann dass alle nötigen Laufzeit-BPLs direkt eingebunden sind (so wie wenn man in der IDE ohne Laufzeit-BPLs kompilieren einstellt) und man trotzdem eine eigene BPL dynamisch zur Laufzeit mit LoadPackage laden kann. Ist doch ein bisschen affig, die halbe VCL mit in die Distri zu packen...

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Also in meiner IDE gibt es bei den Projekteinstellungen keine nach Win32 und Win64 getrennte Package-Auswahl. Entweder man machts für alle Plattformen oder gar nicht.

Stimmt, eine der wenigen Einstellungen die für alles gleich ist.

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Was mich aber grad richtig nervt: Die abgewählten Packages speichert Delphi nicht in den Projekteinstellungen. Sprich nach dem nächsten Öffnen des Projektes kann man die ganze Auswahl wiederholen.

Sollte eigentlich nicht der Fall sein, sondern die nicht angehakten sollten in der dproj unter <Excluded_Packages> gespeichert werden.

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Mich würde interessieren, ob man nicht eine BPL so erstellen kann dass alle nötigen Laufzeit-BPLs direkt eingebunden sind (so wie wenn man in der IDE ohne Laufzeit-BPLs kompilieren einstellt) und man trotzdem eine eigene BPL dynamisch zur Laufzeit mit LoadPackage laden kann. Ist doch ein bisschen affig, die halbe VCL mit in die Distri zu packen...

Es gibt 2 Sachen, einmal die required Klausel in deinem Package. Dort wird angegeben, welche Dinge aus anderen Packages kommen, alles andere wird explizit in die BPL aufgenommen - da kommt bei Nichtbeachtung manchmal die Meldung nach dem Motto, hey du machst da grad VCL Zeugs in dein Package, was aber auch in Package XYZ enthalten ist. Dabei werden alle von der IDE geladenen Packages berücksichtigt. Im requires ist mindestens die RTL aufgelistet.
In deiner Hostanwendung stellst du ein, gegen welche Runtime packages gelinkt wird. Also eine Mindestkonfiguration würde dort nur dein Package auflisten - die RTL wird implizit benutzt, weil sie in deinem Package als requires steht.

[Codehunter]

Moment, ich krieg grad irgendwie Hirnerweichung :D Also der Hostanwendung könnte ich beibiegen dass sie alle Laufzeitbibliotheken direkt eingebunden bekommt. Mein Package dagegen wird die entsprechenden BPLs immer anfordern? Denn eine Auswahl von Laufzeitbibliotheken ist bei meinem Package-Projekt gar nicht vorgesehen.

Ich dachte bisher, wenn die Hostanwendung das entsprechende Laufzeitpackage bereits enthält, würde sich mein dynamisch geladenes Package daraus bedienen. Scheint aber nicht so zu sein :(