Hallo,
wie kriege ich heraus, welche Abhängigkeiten (ocx, dll) bei einem VB5 - Programm bestehen?
Vielen Dank
Helmut
Abhängigkeiten
Hallo Helmut,
der einfachste Weg dies herauszubekommen ist: Mit dem VB Paketersteller ein Setup zu erstellen. Klingt banal - aber so habe ich seinerzeit auch angefangen.
Der VB Paketersteller erzeugt ein Unterverzeichnis, in dem alle notwendigen Dateien liegen. Diese in den Installer einbinden und es sollte laufen...
Die manuelle Art sieht so aus: Alles was unter dem Menuepunkt Projekt > Verweise und Projekt > Komponenten angehakt ist, muss mit hinein. Weil die Welt aber nicht so nett sein kann, gibt es noch eine weitere, wichtige Kleinigkeit: Viele DLLs bzw OCXe haben noch sog. DEP Dateien.
Beispiel:
dialog.ocx
dialog.dep
In dieser Dep (Depend soll es wohl heissen - Abhängigkeit) steht drin, was die DLL oder die OCX Datei ihrerseits wieder benötigt. Sofern er sie finden kann, wertet der VB Paketersteller diese Dateien aus.
Schliesslich und endlich hilft nur eins: Ein Echttest auf einem frisch installiertem Zielsystem.
Leider hat der Installer bis heute keine Routine um automatisiert Hilfestellung zu leisten.
Andreas, mein Angebot steht weiterhin
Vielleicht unterstützen Sie mich in meiner alten Bitte an Andreas Kapust.
Schöne Grüsse
Roland
der einfachste Weg dies herauszubekommen ist: Mit dem VB Paketersteller ein Setup zu erstellen. Klingt banal - aber so habe ich seinerzeit auch angefangen.
Der VB Paketersteller erzeugt ein Unterverzeichnis, in dem alle notwendigen Dateien liegen. Diese in den Installer einbinden und es sollte laufen...
Die manuelle Art sieht so aus: Alles was unter dem Menuepunkt Projekt > Verweise und Projekt > Komponenten angehakt ist, muss mit hinein. Weil die Welt aber nicht so nett sein kann, gibt es noch eine weitere, wichtige Kleinigkeit: Viele DLLs bzw OCXe haben noch sog. DEP Dateien.
Beispiel:
dialog.ocx
dialog.dep
In dieser Dep (Depend soll es wohl heissen - Abhängigkeit) steht drin, was die DLL oder die OCX Datei ihrerseits wieder benötigt. Sofern er sie finden kann, wertet der VB Paketersteller diese Dateien aus.
Schliesslich und endlich hilft nur eins: Ein Echttest auf einem frisch installiertem Zielsystem.
Leider hat der Installer bis heute keine Routine um automatisiert Hilfestellung zu leisten.
Andreas, mein Angebot steht weiterhin
Vielleicht unterstützen Sie mich in meiner alten Bitte an Andreas Kapust.
Schöne Grüsse
Roland
-
Andreas Kapust
- Administrator
- Beiträge: 1085
- Registriert: 29.02.2004, 15:51
- Wohnort: Hamburg
- Kontaktdaten:
Abhängigkeiten
Hi!
Wie sagt man so schön: „Das Problem ist bekannt“.
Darum an dieser Stelle ein kurzer Ausblick auf die kommende Entwicklung.
Eine direkte automatisiert Hilfestellung in dem Sinne wird es nicht geben (da diese zu starr ist und ich wie man am Installer sieht, von solchen Einschränkungen nichts halte). Sie müsste also für jede mögliche Entwicklungsumgebung implementiert werden (eine für VB, eine für .NET o. Delphi).
Vielmehr wird es eine Importschnittstelle geben, die mit z.B. XML- oder Ini-Dateien arbeitet und Anhand von bestimmten Kennungen Dateien o. Programmstarts an der richtigen Stelle einfügt. Dann können für die Entwicklungsumgebung Assistenten entwickelt werden, die diese Import-Dateien erstellen. Das kann am Ende wie folgt aussehen: Über eine Assistenten-Menü wählt man den VB-Assistenten aus, in ihm das Projekt und am Ende werden die Dateien und Runtime im Programmstart eingefügt.
Das hat den Vorteil, dass hier auch fertige Import-Dateien für Datenbanken etc. mitgeliefert werden könnten und die Assistenten von Drittanbietern kommen könnten.
Dieses zusammen mit Multilanguage-Unterstützung sind die großen kommenden Erweiterungen. Bei beiden kann ich aber keinen Erscheinungstermin nennen sondern nur when it’s done.
Gruß
Andreas Kapust
Wie sagt man so schön: „Das Problem ist bekannt“.
Darum an dieser Stelle ein kurzer Ausblick auf die kommende Entwicklung.
Eine direkte automatisiert Hilfestellung in dem Sinne wird es nicht geben (da diese zu starr ist und ich wie man am Installer sieht, von solchen Einschränkungen nichts halte). Sie müsste also für jede mögliche Entwicklungsumgebung implementiert werden (eine für VB, eine für .NET o. Delphi).
Vielmehr wird es eine Importschnittstelle geben, die mit z.B. XML- oder Ini-Dateien arbeitet und Anhand von bestimmten Kennungen Dateien o. Programmstarts an der richtigen Stelle einfügt. Dann können für die Entwicklungsumgebung Assistenten entwickelt werden, die diese Import-Dateien erstellen. Das kann am Ende wie folgt aussehen: Über eine Assistenten-Menü wählt man den VB-Assistenten aus, in ihm das Projekt und am Ende werden die Dateien und Runtime im Programmstart eingefügt.
Das hat den Vorteil, dass hier auch fertige Import-Dateien für Datenbanken etc. mitgeliefert werden könnten und die Assistenten von Drittanbietern kommen könnten.
Dieses zusammen mit Multilanguage-Unterstützung sind die großen kommenden Erweiterungen. Bei beiden kann ich aber keinen Erscheinungstermin nennen sondern nur when it’s done.
Gruß
Andreas Kapust