Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Komponenten und Com Server


3 replies to this topic

frank@wenner-online.de

frank@wenner-online.de
  • Full Members
  • 4 posts

Posted 21 June 2007 - 19:01

Hallo Install Forum,

ich habe mit InstallShield 12 ein Setup erstellt und diese soll nun die Richtlinien fpür das Vista Logo erfüllen.
Vorab:
Wir haben ein Produkt, dass auch ca. 1500 Komponenten besteht. 90% davon sind Com Komponenten (DLLs & AxcExe) alles erstellt mit VB6.

Heute habe ich ca. 30 Komponenten erstellt die per dynamischer Verknüpfung jeweils viele der DLLs oder AcxExe enthalten.

In der Vista Logo Testliste steht, dass man immer nur eine Com Komponente in einer Installer Komponente haben darf und diese das "KeyFile" sein soll.

Fragen:
1.1) Ist dem wirklich so? Muss ich also für 1500 Dateien auch 1500 Installer Komponenten erstellen? Das wäre der blanke Wahnsinn/Horror sad.gif
1.2) geht das auch anders?

2.) Was bedeutet genau KeyFile?

Ich bin etwas unter Zeitdruck, ich würde mich freuen, wenn mir hier jemand Licht in Dunkel bringen könnte.

Gruß
Frank Wenner

Edited by frank@wenner-online.de, 21 June 2007 - 19:16.

Gruß
Frank Wenner
Senior Software Developer

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 22 June 2007 - 08:42

Ja das ist so. Bei dynamischer Einbindung der Dateien sollte InstallShield "on the fly" beim Build die entsprechenden Components erstelen - was bisweilen problematisch ist. Eine andere Möglichkeit wäre, die Dateien bzw. den ganzen Ordner ins InstallShield zu ziehen, wobei im InstallShield die "Est Practices" Option eingeschaltet sein sollte (ist sie normalerweise). Dann legt InstallShield die entsprechenden Components für dich an (einmalig, statisch).

Jede Komponente hat ein Schlüsselelement, entweder eine Datei oder einen Regstry-Eintrag. Dieses Element wird beim Starten der Applikation geprüft und wenn es fehlt wird das Setup repariert. Die Schlüsseldatei spielt auch eine wichtige Rolle beim Versionsvergleich im Falle eines Updates.

frank@wenner-online.de

frank@wenner-online.de
  • Full Members
  • 4 posts

Posted 22 June 2007 - 08:53

Hallo Herr Krüger,

erst mal DANKE für die schnelle Antowrt.

Eine Kleinigkeit wäre da noch. Heute ist es bei uns so das jeder Entwickler bei uns einfach nach "Lust und Laune" neue DLLs entwefen kann und diese zentrall im Netz abgelgt und mit einer alten InstallShiled Version (2.03 Express) einfach alle Dateien aus den dort vorhandenen Dateigruppen entferne und wieder neu zugeordnet werden. Damit sind dann auch immer alle evtl. neuen Dateien autom. im Setup.

Solche Gruppen von Dateien scheint es ja nur noch in Form von Komponenten in den aktuellen InstallShield Versionen zu geben. Und diese sagen ja immer nur eine COM Datei. ODer habe ich noch was übersehen?

Gibt es andere Alternativen OHNE im Setup immer von Hand die neuen Dateien einbinden zu müssen?

z.B.:
Könnte mal die COM DLLs einfach OHNE Registrierung auf das Zielsystembringen und im Nachlauf über "Custon Action" einfach alles registrieren? Oder verstößt dann das auch wieder gegen die "Guidelines" und "Best Practices"?

... warum wird einen das immer so schwer gemacht mad.gif

Edited by frank@wenner-online.de, 22 June 2007 - 08:55.

Gruß
Frank Wenner
Senior Software Developer

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 June 2007 - 11:30

Ja, das würde gegen die Best Practices verstoßen. Da bei diesem Szenario Small und Minor Updates sowieso nicht funktionieren, Sie also ausschließlich Major Upgrades verwenden können, sind dynamische Links relativ unproblematisch.