D2007 und Module

[hanspeter]

Hallo,

ich habe ein größeres Projekt unter D2007 modularisiert.
Dazu habe ich unter Verwendung des Hydra-Pluginsystems eine Reihe von Funktionen in dll ausgelagert.

Eine Plugin-Schnittstelle erlaubt den Aufruf einzelner Module, wobei deren Interfacebeschreibung in einem statischen Record erfolgt.
Der Aufruf ist für alle Module gleich.
Die Parameterversorgung erfolgt über eine einheitliche Kommandoschnittstelle (Kommando, Stringparameter, Integerparameter)

Delphi-Quellcode:

Beispiel:
  CreatePlugin(@AuswahlListe);                     // Statischer Record Titel,dll-Name,Modulname,Hilfedatei, Freigabe Toolbutton im Framework.
  InitDate(AuswahlListe,'P','',GruppenID);         // Bearbeitungs ID
  InitDate(AuswahlListe,'A','',ComData.ArbPlatz);  // Arbeitsplatz

Das funktioniert auch alles wie gewünscht und ist recht flott.
Das Hauptprogramm war vorher 11 MByte groß und eine einzige Exe.
Jetzt ist es noch 3,2 MByte groß, dazu kommen 1.3 MByte in 8 dll.

Wenn man von den vielen kleinen Problemen mit D2007, gerade an den Interface-Schnittstellen absieht, war die Entwicklung eigentlich praktikabel.
Unter D2007 ging das von verlorenen Parametern über sporadische Speicherschutzverletzungen bis zum blue screen beim Aufruf einer dll. (Etwa 1 mal am Tag)

Jetzt kommt aber das eigentliche Problem.
Hydra benötigt Laufzeitpackages von VCL,RTL,HydraCore.
Dazu kommen noch BPL, welche eine Klasse mit Registerclass registrieren.
Das sind bei mir eine BPL von Fastreport und eine von IBDAC.
Also recht überschaubar.

Aber jetzt kommt der Hammer.
Ich habe das Programmsystem auf einem Delphi freien Rechner installiert.
Da verlangt er dann eine BPL nach der anderen als Laufzeitbibliothek.

Insgesamt habe ich etwa 70 bpl kopieren müssen.
Da ergibt sich für das nun schlankere Programm eine Laufzeitumgebung, die im konkreten Fall, mit
41,495 MByte zuschlägt.
Ich verwende ausschließlich kommerzielle Tools. Das da auch ein bischen geschlampt wurde, erkennt man daran,
das z.B. die DesignIDE.bpl als Laufzeitmodul angefordert wird.

Gibt es ein Programm, was mir solche Abhängigkeiten von BPL auflistet?
Da Delphi beinahe willkürlich mal eine bpl mitcompiliert, müsste diese bei einem Update mit ausgeliefert werden.
(D2007 kann bei mir nach einem Neustart nicht auf verbundene Netzlaufwerke zugreifen. Diese muss ich in Delphi manuell öffnen.)
Gibt es ein Programm, was Abhängigkeiten prüft und mir ein Updateset aufbereitet?
Ich habe inzwischen allerdings auch grundsätzliche Zweifel, ob der gewählte Weg überhaupt praktikabel ist.


Für ein paar Tips dankbar.

Gruß
Peter

[Bernhard Geyer]

DependencyWalker kann (falls die BPL nicht alle dynamisch geladen werden) sowas (BPL = DLL + VCL-RTL-Extensions)

[hanspeter]

Zitat von Bernhard Geyer:

DependencyWalker kann (falls die BPL nicht alle dynamisch geladen werden) sowas (BPL = DLL + VCL-RTL-Extensions)

Offensichtlich werden die alle dynamisch geladen.
Beim Programmstart kommt ja immer die Meldung "kann nicht gestartet werden weil ... bpl fehlt.
Da ist wohl jede bpl mit jeder verbandelt.
Es werden selbst bpl angefordert, die ich mit Sicherheit an keiner Stelle im Programm verwendet habe.
z.B. BDE oder designide.

Gruß Peter

[mschaefer]

Ja Du nicht, aber wahrscheinlich eine Deiner Fremdkomponenten. BDE werden oft von Datensensitiven Komponenten mit verwendet, die sich auch die lokalen Datenbanken zur Verwendung offenhalten wollen. DesignIde ist überall dort zu finden, wo mit Designtime-Editoren was eingestellt werden kann.

Grüße // Martin

[hanspeter]

Zitat von mschaefer:

Ja Du nicht, aber wahrscheinlich eine Deiner Fremdkomponenten. BDE werden oft von Datensensitiven Komponenten mit verwendet, die sich auch die lokalen Datenbanken zur Verwendung offenhalten wollen. DesignIde ist überall dort zu finden, wo mit Designtime-Editoren was eingestellt werden kann.

Grüße // Martin

Ich habe das gleiche Projekt jetzt mal unter D7 kompiliert.
Da werden weniger BPL benötigt.
Ich glaube bei D2007 hat es sich CG einfach gemacht und verlangt kurzerhand alle registrierten (installierten) BPL
als Laufzeitumgebung.

Das Programm ist durch Laufzeitbibliotheken ca. 5 Mbyte kleiner geworden, benötigt jetzt > 40 Mbyte Laufzeitumgebung.
Eigentlich keine akzeptable Lösung.

Gruß
Peter

[Elvis]

In den Projektoptionen steht, welche Packages du benötigst.
Da sollten nur die drin stehen, die du auch wirklich benötigst.

btw, ich hoffe mal, zukünftige Versionen von Hydra kommen mit Interfaces und DLLs aleine aus, ohne Packages.
Delphi-Packages sind einfach ein einziger, großer Designfehler, sie zwingen dich dazu, nur gegen eine einzige RTL-Version mit exakt dem gleichen Compiler zu kompilieren...

[hanspeter]

Zitat von Elvis:

In den Projektoptionen steht, welche Packages du benötigst.
Da sollten nur die drin stehen, die du auch wirklich benötigst.

btw, ich hoffe mal, zukünftige Versionen von Hydra kommen mit Interfaces und DLLs aleine aus, ohne Packages.
Delphi-Packages sind einfach ein einziger, großer Designfehler, sie zwingen dich dazu, nur gegen eine einzige RTL-Version mit exakt dem gleichen Compiler zu kompilieren...

Exakt die Packages, welche ich benötige stehen auch in den Projektoptionen.
Das Programm startet einfach nicht, wenn der ganze sonstige Schrott fehlt.

Wenn Hydra mit Interface und dll alleine auskommen soll, dann müßte ja ein Com-ähnliches Modell realisiert werden.
Das Problem mit Hydra ist ja, dass alle BPL, welche Registerclass verwenden, als Laufzeit-BPL bereitgestellt werden müssen.
So wie es aussieht, werde ich wohl die gesamte Modularisierung wieder aufgeben und das Programm monolithisch compilieren.

Hat wer eigentlich Erfahrungen wie ein Hydramodul unter C# und Net compiliert mit Delphi zusammen arbeitet?


Gruß
Peter