Unzuverlässige Steuerung durch AutoIT

MB0902

Hallo zusammen,

ich erstelle derzeit etliche Scripts zur automatischen Installation bestimmter Programme.

Dazu verwende ich eine virtuelle Maschine, auf der außer XP Professional, allen aktuellen Servicepacks und Patches sowie dem Internet Explorer 7 nichts installiert ist. Von diesem Zustand habe ich einen Snapshot gemacht, so daß ich für jeden Test ein jungfräuliches XP zur Verfügung habe. Somit sind auch die Testbedingungen immer dieselben.

Was mir als AutoIT-Neuling auffällt ist, daß die Steuerung der Programme durch AutoIT nicht zuverlässig ist.

So kommt es immer wieder vor, daß ich ein Script erstellt habe, das auf dem jungfräulichen Windows völlig einwandfrei durchläuft und das Programm tadellos installiert.

Stelle ich den jungfräulichen Zustand wieder her und lasse das unveränderte AutoIT-Script erneut laufen, kann es sein, daß es wieder sauber durchläuft - aber genauso gut kann es auch einfach stehen bleiben, obwohl im Code kein Fehler steckt.

Ich habe mir schon überlegt, ob das Script zu schnell abgearbeitet wird und das zu installierende Programm die von AutoIT gelieferten Eingaben deshalb nicht verarbeiten kann. Darum habe ich hie und da "Sleep"-Anweisungen eingebaut - die an mancher Stelle tatsächlich helfen.

Ganz aktuell sitze ich an der Installation des Programms CDex. Die Installation läuft jedesmal sauber durch - bis zum Schluß die Abfrage kommt, ob das Readme-File gelesen werden soll. Hier soll AutoIT den Befehl Send ("!n") schicken, damit das Fenster geschlossen wird. Hat auch schon funktioniert, jetzt aber nicht mehr, obwohl absolut nichts am Programmcode geändert wurde.

Solche Situationen tauchen immer wieder auf. Zigmal getestet, zigmal funktioniert - dann plötzlich nicht mehr.

Grundsätzlich würde mich interessieren, ob andere ähnliche Beobachtungen gemacht haben und ob es Möglichkeiten gibt, daß AutoIT die Programme zuverlässiger steuert - bzw. wo mein Fehler liegt.

Viele Grüße
Michael

ChaosKeks

Oder du benutzt die falschen Commands

Guck dir statt sleep -> WinWait(Active)
und statt send -> alle ControlCommands an!

**Raupi**

@MB0902 . Poste doch mal Code zum testen. Sonst schießen wir sowieso nur ins blaue .

MB0902

Zitat von Raupi

@MB0902 . Poste doch mal Code zum testen. Sonst schießen wir sowieso nur ins blaue .

Das Script FPInstall, welches den Flashplayer installiert, lief anfangs tadellos. Mittlerweile wird das FlashPlayer-Setup überhaupt nicht mehr gestartet, obwohl weder am Script was geändert wurde, noch die Setup-Datei durch eine aktuellere ersetzt oder an der Windows-Installation was gedreht wurde.

Das Script FFKonfig konfiguriert FireFox. Es läuft anstandslos durch, nur wird die Startseite sporadisch nicht eingetragen.

Eben habe ich wie im Ursprungspost beschrieben über virtuelle Maschine/Snapshot ein jungfräuliches Windows hergestellt, dann zuerst das FireFox-Installationscript gestartet, anschließend dieses Konfigurationsscript. Die Startseite wurde nicht eingetragen. Ich habe das Konfigurationsscript sofort ein zweites Mal gestartet - diesmal wurde die Startseite eingetragen.

Dann habe ich wieder ein jungfräuliches Windows hergestellt, Installationsscript und anschließend Konfigurationsscript laufen lassen - beides lief anstandslos durch inkl. Eintragen der Startseite

Dritter Versuch - ebenfalls mit frischer Windowsinstallation. Ergebnis: anstandlose Abarbeitung der Scripts.

Fazit: zweimal gehts, einmal nicht.

Gruß
Michael

MB0902

Zitat von ChaosKeks

Oder du benutzt die falschen Commands

Guck dir statt sleep -> WinWait(Active)
und statt send -> alle ControlCommands an!

Das hab ich natürlich schon gemacht. Sind die ControlCommands "sicherer" und zuverlässiger, als "Send"?

michael

Mit einigen Jahren Erfahrung im Deployment würde ich das Problem anders sehen:

(Kleiner Einschub: Es gibt die sogenannte 80:20-Regel. Das bedeutet:

Um 80 % einer Arbeit zu erledigen, braucht man 20% der Zeit,

die letzten 20% verschlingen hingegen den Grossteil der Zeit - die 80% der Zeit.

Fazit: Mensch sollte genau abwägen, wie präzise die Arbeit (das Script)

werden soll / muss)

Fazit: je höher der Anspruch an fehlerfreies Verhalten des
Scriptablaufes sein soll, desto höher wird der Aufwand bei der
Programmierung sein.

Hier: Das Setup und das steuernde AutoIT-Script laufen linear und
parallel zueinander ab. Darin ist implizit harteincodiert: Das
Zeitverhalten des Setups und des AutoIT-Scriptes passen perfekt
zusammen.

Bei kleinen Abweichungen vom Zeitverhalten KANN es aber zu Diskrepanzen
führen - Script- und Setup- Verhalten / Ablauf "passen" nicht mehr
zueinander.

Abhilfe: Da das setup nicht veränderbar ist, muss das steuernde
AutoIT-Script so verändert werden, dass es jeden möglichen zeitlichen
oder logischen Ablauf des Setups bearbeiten kann. Das kann mensch
z.Bsp. so einbauen, das das Script in einer Schleife alle möglichen zu
bearbeitenden Meldungen / Buttons o.ä. abfragt und gegebenenfalls
bearbeitet.

Mit sinnvoll gewählten Pausen kann mensch das so optimieren, das die Schleife optimal oft / selten abgearbeitet wird.

Natürlich muss mensch dann auch ein geplantes Ende des Scriptes
einbauen: Nach erfolgreicher Bearbeitung der Ende-Meldung des Setups,
nach Timeout (vermutlich also kein erfolgreiches Setup), usw.

Je nach Anspruch kann das dann weiter verfeinert werden (Qualität höher bedeutet: Aufwand höher).

XTC99

Hier meine Variante von Adobe FlashPlayer Plugin.
Und mit TuneUp 2007.

Geht auch mit FireFox, nur mit AutoIt selbst habe ich probleme

Ciao
XTC99

Spoiler anzeigen

[autoit]

#RequireAdmin
#cs ----------------------------------------------------------------------------
AutoIt Version: 3.3.0.0
Author: XTC99

Script Function:
Automatic Silent Installtion
#ce ----------------------------------------------------------------------------

[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

;~Define Variables
DIM $setup = @ScriptDir & "\install_flash_player.exe"
DIM $setup_ie = @ScriptDir & "\install_flash_player_ax.exe"