6 replies to this topic

[Andock]

Hallo,

ich habe eine für mich katastrophale Entdeckung gemacht. Da ich es aber nicht glauben kann, frage ich zunächst, ob jemand dieses Problem bestätigen kann.

Wenn ich mit InstallShield 2008 unter Windows XP ein Setup erzeuge, in denen bekannte Komponenten (wie z. B. ActiveReports oder FlexGrid8) enthalten sind, wird dieses später auf einem jungfräulichen WinXP oder Vista oder Win7 Rechner ohne Probleme ausgeführt und die Anwendung lässt sich starten.

Nun bin ich auf Windows7 (ebenfalls 32Bit!) umgestiegen und habe mit InstallShield EXAKT DAS GLEICHE ISM-Projekt geöffnet und ein Setup erzeugt (keine Fehler wurden gemeldet). Wenn ich deses nun auf einem jungfräulichen WinXP (bisher nur XP getestet!) ausführe und das Programm anschließend starten will, erscheint für FlexGrid die Meldung...

"Das Steuerelement 'VSFlexGrid' konnte nicht aus vsflex8.ocx geladen werden. Ihre Version von vsflex8.ocx ist möglicherweise veraltet. Stellen Sie sicher, daß Sie die Version des Steuerelements verwenden, die mit Ihrer Anwendung geliefert wurde."

...für ActiveReports (und viele andere Komponenten) die Meldung:

"Laufzeitfehler '-2147319779 (8002801d)':
Automatisierungsfehler
Bibliothek nicht registriert. "

Hatte schon die Befürchtung, die Jungs von installshield wollten nur wieder Kasse machen und man MÜSSE auf IS2009 updaten, aber negativ. Auch mit der Testversion des IS2009 inkl. SP2 das gleiche Ergebnis.

Erzeuge ich das Setup wieder auf einem XP-Rechner - alles wieder einwandfrei!

P.S. Einige OCX-Komponenten funktionieren übrigens (es ist somit nicht für alle OCX-Dateien!) - ebenso ALLE, die per MSM-MergeModul dem IS-Projekt hinzugefügt sind.

UND wenn ich am Ziel-PC dann in das System32-Verzeichnis wechsle und z. B. die vsFlex8.ocx manuell registriere, funktioniert die Anwendung, die das FlexGrid verwenden. Gleiches gilt für ActiveReports usw...

Mit anderen Worten, mir kommt es so vor, als würd ein unter Windows7 erzeugtes Setup die Registrierung nicht sauber auf einem Ziel-Rechner ausführen können. Vielleicht werden irgendwelche Kernbibliotheken ins Setup eingebunden, die unter WinXP nicht kompatibel sind!?!?

Kann mir jemand hierzu etwas sagen oder gar helfen?

Edited by Andock, 06 August 2010 - 14:08.

[Stefan Krueger]

Ich weiß nicht, wie du diese Dateien einbindest, aber du solltest nicht den Dependency Scanner verwenden sondern die Dateien expliziet (sofern verfügbar als Merge Modul) hinzufügen.

Was am neuen Setupü fehlt kannst du herausfinden, indem du die beiden Varianten (von Win7 und XP) der .msi Dateien mit dem MSI Diff Tool aus den InstallShield vergleichst.

[Andock]

Danke, zwischenzeitlich habe ich (genauer gesagt unsere Entwickler) das Problem erkannt.

Bisher hatte ich bei allen Komponenten (OCXe) kein Häkchen für "Selbstregistrierend" gehabt. Das funktionierte mit WinXP über Jahre hinweg ohne Probleme!

Nun aber scheint es Windows 7 hier genauer zu nehmen (obwohl die Setuperstellung keine Meldung ausspuckt!). Bei einigen - nicht bei allen - muss hier wohl das Häkchen gesetzt sein.

Komisch nur, dass bei manchen OCXe (die definitiv per regsvr32 zu registreien gehen) das Häkchen auch bei Windows 7 nicht gesetzt sein muss - bei anderen wiederum muss es. Woran erkennt man, ob für eine Komponente "Selbstregistrierend" angekreutzt sein muss oder nicht? Ich dachte immer daran, ob sie mit regsvr32 zu registreien geht oder nicht...!?

Erkannt haben wir es mit einem MSI-Vergleichstool (also ähnlich Deinem Vorschlag mit "MSI Diff Tool"). Da fehlten nämlich Reg-Werte...!

[Stefan Krueger]

Standardmäßig werden die COM-Daten entweder beim Hinzufügen der Datei zum Projekt oder beim Build (je nach Einstellung) extrahiert. Dann sollte es nicht mehr nötig sein, auf dem Zielsystem den regsvr32 aufzurufen (was das Häkchen bei Selbstregistrierend in etwa bewirkt).

[Andock]

> Standardmäßig werden die COM-Daten entweder beim Hinzufügen
> der Datei zum Projekt oder beim Build (je nach Einstellung) extrahiert.
Was genau meinst Du mit "je nach Einstellung"?

> Dann sollte es nicht mehr nötig sein, auf dem Zielsystem den regsvr32 aufzurufen
Ich hatte das gleiche gedacht - irgendwo im weiten WWW sogar gelesen, das dieses Häkchen setzen zwischenzeitlich sogar mehr oder weniger obsolet sei!?!

Aber dem ist (zumindest unter Windows 7) nicht so. Habe mehrfach Testprojekte in InstallShield erzeugt und auch in einer Testumgebung die Trial des Installshield 2010 mit frischem Windows 7 (ebenfalls 32 Bit) aufgesetzt. Die benötigten Komponenten habe ich dabei manuell hinzugefügt und die Einstellung "Beim Build wird eine COM-Extraktion ausgeführt" als auch "COM-Extraktion wird sofort beim Hinzufügen..." getestet.

Egal ich ich es testete - es klappte nicht.

OK, anders gefragt. Kann dieses Häkchen Deiner Meinung nach in bestimmten Situationen auch negativ sein, wenn ich es prinzipiell bei COM's setze, die auch mit "regsvr32" zu registrieren gehen?

[Stefan Krueger]

[Andock]

> Geht regsvr32 auf dem Build-Rechner
Yep, geht einwandfrei!

> Gibt es bei der Extraktion beim Build Fehlermeldungen?
Keinerlei Fehlermeldungen oder Warnungen. Das war ja gerade das gemeine ;-)

> Funktioniert es, wenn du UAC mal testweise abschaltest für den Build?
War das erste, was ich tat...

Ohjee, ich merke schon, da werde ich wohl jetzt immer mit einer "BlackBox" leben müssen...