none
Fehlermeldung und Fehlercode abfangen RRS feed

  • Frage

  • Hallo allerseits!

    Ich möchte zwecks Deployment den Fehlercode mit der Fehlermeldung von einer Installation abfangen.

    Die Installation eines beliebigen Applikation soll mit einem eigenen Tool gestartet werden.

    Danach abwarten bis die Installation fertig bzw. abgeborchen wird und den entsprechenden Fehlercode mit

    der dazugehörigen Fehlermeldung abfangen.

       System.Diagnostics.Process p = new System.Diagnostics.Process();
    
       // Die ensprechende Setup.exe von einer beliebigen Applikation
    
       p.StartInfo.FileName = "\"" + _args[0].ToString() + "\" "; 
    
       // Die passenden parameter. Bsp. Silent-Parameter
    
       p.StartInfo.Arguments = _args[1].ToString();
    
       p.StartInfo.UseShellExecute = false;
    
       p.StartInfo.CreateNoWindow = true;
    
       // Hier soll die Standartausgabe kommen
    
       p.StartInfo.RedirectStandardOutput = true;
    
       // Hier soll die entsprechende Fehlermeldung kommen
    
       p.StartInfo.RedirectStandardError = true;
    
       p.Start();
    
       string outMSG = p.StandardOutput.ReadToEnd();
    
       string outERR = p.StandardError.ReadToEnd();
    
       int errCode = p.ExitCode;   
    
       p.WaitForExit();
    
       p.Close();
    
       p.Dispose();

     

    So, jetzt kann man bsp. einen net use Befehl ausführen und man kann die entsprechende Meldung abfangen.

    Doch viele Installationsdateien(MSI, InstallShield, InnoSetup usw) haben Ihre eigenen Codes und Meldungen.

    Bsp. Um Powershell zu installieren muss die Installation mit dem Administrator-Konto gestartet werden, sonst

    gibt es eine MessageBox da mir die Administrativen Rechte fehlen. Jedoch bekomme ich diese Meldung über

    dern Stream nicht herein aber den Fehlecode schon. Bei anderen Installationen bekomme ich weder

    Fehlercodes noch Fehlermeldungen zurück.

    Jetzt meine Frage, gibt es eine Möglichkeit mittels .NET auf die Fehler der Installationen zu reagieren?

    Wäre euch sehr dankbar wenn ihr mir dabei weiter helfen könnt.

     

    Danke und Lg

    unlading-planet

     

    Donnerstag, 22. Juli 2010 15:26

Antworten

  • Hallöchen,

    ich glaube wir reden bisserl aneinander vorbei. Nur weil die von dir genannten Installer MSI Technoligien verwenden heisst das nicht das sie auch wie MSI Installer arbeiten und die Logs auch genau so schreiben. In der Praxis sehen die Sachen meistens anders aus.
    [QUOTE]
    Ein 1703 Fehlercode würde bsp. bei einem Produkt darauf deuten das bsp. die Lizensdatei nicht gefunden wurde und bei einem anderen würde es bedeutet das administative Rechte fehlen
    [/QUOTE]

    Diese Art von Problemen gibt es mit Installern die MSI Technologien verwenden, leider.  Installaware und Wise Installer.

    habe ich aus dem Grund nicht erwähnt da diese wie InstallShield (iss) arbeiten. Mit Advanced Installer habe ich sehr sehr wenig zu tun gehabt. Windows Installer Tool, Orce, InstED etc. werden verwenden um die Parameter ausfindig zu machen und um evtl. MST Dateien zu erzeugen.
    WIX ist noch zu neu und ich habe noch keine Software welche diese Technologie verwendet gesehen.


    Ich glaube das es besser wäre den Thread zu schliessen da es anscheinend doch keine Möglichkeit gibt von verschiedenen Installer Technologien die Fehlercode mit den entsprechenden Fehlermeldung zu kommen. Es bringt auch nicht eine Datei mit allen möglichen Code zu erstellen un diese zu verwenden oder auch die Logdatei auszulesen. Da die Installation vielleicht erfolgeich ablaufen könnte aber ein Komponente nicht installiert wurde.

     

    Jedenfalls bedanke ich mich für das Brainstorming und wünsche noch ein schönes Wochenende.
    Lg unlading-planet

     


    Freitag, 23. Juli 2010 14:39

Alle Antworten

  • Hallo,

    da sich die unterschiedlichen Installationsprogramme (meiner beschränkten Erfahrung nach)
    doch deutlich unterscheiden, gibt es dafür keine allgemein gültige Lösung.

    Im allgemeinen liefern alle Installationsprogramme (so sie sich wirklich so nennen können)
    einen Exit Code zurück und sollte auch dokumentiert sein, so z. B. der Windows Installer

    Dafür hat aber jede Umgebung ihre eigenen Regeln. Und wenn man dort wiederum Pakete
    anderer Installer einbettet (z. B. bei InnoSetup eine MSI) so geht die Informationen in
    der Kette schnell mal verlustig.

    Soweit es sich um .NET Programme handelt sollte man auf die dortige Installer-Technologie
    setzen, die auch das Einbetten von Komponenten ermöglicht, so sie es vorsehen.
    Sich einen "eigenen Setup" zu basteln leistet den Problemen am Ende nur Vorschub.

    So wäre eine Möglichkeit WiX (oder eine andere Installertechnologie ) zu verwenden.
    Die Einarbeitung sollte man in Kauf nehmen, da dort viel an Erfahrung eingeflossen ist,
    die man bei seinen gelegentlichen Setups nicht neu machen will/sollte.

    Wo das nicht möglich ist, kann man den Weg wie der SQL Server 2008 Setup gehen.
    Dort werden die Systemvoraussetzungen zu Beginn und nach wesentlichen Schritten geprüft .
    Was relativ komplex ist (und auch nicht immer das gewünschte Ergebnis liefert).

    Gruß Elmar

    Donnerstag, 22. Juli 2010 20:17
    Beantworter
  • Hallo Elmar,

    danke vorerst für deine Antwort.
    Beim SQL-Server wurde der Intallationsablauf grundlegend geändert soweit ich weiss. Es wird in jedenfall eine Logdatei geschireben und egal wo die Installation abricht, wird auch ein richtiger RollBack durchgeführt so das wirklich nichst mehr da ist ausser die Logdatei(n).
    In diesem Fall wäre das ein Traum wenn jeder Installer, auch wenn sie ihre eigenen Wege gehen, aber doch mehr Info geben könnten.

    Soweit mir bekannt, ist WIX und die ganzen WIX-Tools erst mit WindowsInstaller 5.0 eingeführt worden. Was wiederum bedeutet das ausser Microsoft (vereinzelnt) diese neue Technologie sehr gering verwendet wird.

    Doch leider gibt es eben noch viele andere Installer und ich dachte mir das es vielleicht ein COM-Objekt oder eine API oder ähnliches geben könnte. Etwas besseres als die Prozess-Klasse.


    [Quote]
    da sich die unterschiedlichen Installationsprogramme (meiner beschränkten Erfahrung nach)
    doch deutlich unterscheiden, gibt es dafür keine allgemein gültige Lösung.
    [/Qoute]

    Wahrscheinlich wird es eh keine Lösung dafür geben. Danke dir trotzdem und

    Lg

    unlading-planet

    Freitag, 23. Juli 2010 05:59
  • Hallo U.,

    Die meisten Installationen werden heutzutage (zumindest unter der Haube) mit MSI-Technologie ausgeführt.
    Insofern ist es für diese Hauptgruppe zumindest möglich, die Meldungen (ggf. auch sehr detailliert) aus einer LOG-Datei einzusehen:

    [How to Interpret Windows Installer Logs - Richard's Weblog - Site Home - TechNet Blogs]
    http://blogs.technet.com/b/richard_macdonald/archive/2007/04/02/how-to-interpret-windows-installer-logs.aspx

     


    ciao Frank
    Freitag, 23. Juli 2010 06:38
  • Hallo Frank,

    [QUOTE]
    Die meisten Installationen werden heutzutage (zumindest unter der Haube) mit MSI-Technologie ausgeführt.
    [/QUOTE]

    Das gilt leider nur bei InsallShield ab Version 6.0. Diese unterstützen mt dem Parameter /v weitere MSI parameter bsp.(/v"qb! /L"C:\LogFile.txt" usw.").

    Lg
    unlading-planet

    Freitag, 23. Juli 2010 06:49
  • Hallo unlading-planet,

    Die meisten Installer, die diesen Namen verdienen, haben die Möglichkeit den Installationsablauf zu protokollieren. Mach Dir eine Liste mit den switches, die das detaillierte Schreiben von Protokolldaten bewirken sowie mit deren Speicherort (findest Du in der Dokumentation der Installer). Dann führst du die Installer aus (über Process.Start wie gehabt) und läßt Dich über FileSystemWatcher benachrichtigen, ob sich die Logdatei geändert hat. Ändert sich die Logdatei über eine gewisse Zeit nicht (hier sind Erfahrungswerte gefragt), kannst Du vermuten, dass die Anwendung evtl. auf Benutzereingabe wartet oder hängt. Schön wäre es, wenn man die Protokolldatei während des Schreibens mitlesen könnte, aber viele Installer öffnen diese verständlicherweise im Exklusivmodus (man könnte "schattenkopieren" u.ä., führt aber hier zu weit).

    Gruß
    Marcel

    Freitag, 23. Juli 2010 06:52
    Moderator
  • Hallo,

    nein, eine allumfassende Lösung gibt es meiner Meinung und Erfahrung nach nicht.
    Man muß genau schauen, welche Software man installieren will und welche
    Setup Plattform(en) dabei eingesetzt wird.

    Und manchmal kann nichts weiter tun, als am Ende das erwartete Installationsergebnis
    zu prüfen. Was schon deswegen nicht ganz einfach ist, weil der Anwender im Dialog u. U.
    die Installationsverzeichnisse ändert.

    Es gibt nunmal sehr viele Installerplattformen. Gründe dafür gibt es unterschiedliche.
    Anfänglich lag es an den Mängeln der Microsoft Setup Routinen - länger aktive Entwickler
    kennen noch den "Acme Setup" und Visual Basic Setupprojekte etc.
    Um diese zu verbessern, sind Installer wie Inno Setup oder NSIS (ehedem für WinAmp) entstanden.

    Und jeder der Installer -  von der Handvoll, die ich andeutungsweise kenne,
    weil ich mal das eine oder andere Problem lösen mußte - hat seine eigene
    Infrastruktur im Laufe der Jahre entwickelt. Einige (wie Installshield) setzen
    mttlerweile als Backend die Windows Installer Datenbank ein.

    Und mit dem Windows Installer, der mittlerweile fast jedes Szenario abbilden kann,
    können sich nicht alle anfreunden,  da er ohne Nachhilfe relativ unhandlich bei
    größeren Paketen wird.

    WiX ist ursprünglich ein von einem Microsoft Mitarbeiter ins Leben gerufenes
    unabhängiges Projekt, das schon einige Jahre der Reifezeit hinter sich hat.
    Es ändert nichts an dem Windows Installer selbst, sondern stellt vielmehr
    eine Möglichkeit dar, Setup Projekte über eine Xml-Spezifikation zu erstellen.

    Der SQL Server Setup (ähnlich auch Office) basiert auf dem Windows Installer,
    fügt jedoch weitere Funktionalität hinzu, wie Integritätsprüfungen uam.
    Nur sitzen dort ganze Teams an der Entwicklung - was sich ein kleines
    Entwicklerteam kaum leisten kann.
    Und eine 100% Garantie für eine "positive Installationserfahrung" kann dort
    ebensowenig gegeben werden.

    Gruß Elmar

    Freitag, 23. Juli 2010 07:30
    Beantworter
  • Hallo Marcel,
    die Idee ist nicht schleht abr doch enbisschen riskant. Die ganzen switches fü die Logausgabe u. silentinstalationen ist nicht das Problem.
    Mi einem Filesystemwatcher die Logdatei überwachen lassen wäre keine gute Lösung.
    Grund dafür wäre die die Installationsdauer verschiedener Applikationen. Bsp. AutoCAD, CreativeSuite, Office 2010 mit MUI usw.
    Diese haben 3-4 GB Sourcen und bei der Intsllation kann es vorkommen das 5-10 min kein Logeintrag geschrieben wird weil die aktuelle Aktion noch nicht fertig ist und wenn fertig ist es schwer heraus zu finden Ob die Installation erolgreich war oder nicht.
    Weiter sollten keine Benutzereingaben notwendig sein (silent). Was wiederum bedeutet das etwaige Eingaben mittels AutoItX oder anderen tools realisiert werden sollte.


    Bsp. einer MSI-Logausgabe
    [code]
    Aktion beendet um 17:11:11: LaunchConditions. Rückgabewert 1.
    Aktion gestartet um 17:11:11: FindRelatedProducts.
    Aktion beendet um 17:11:11: FindRelatedProducts. Rückgabewert 1.
    Aktion gestartet um 17:11:11: ValidateProductID.
    Aktion beendet um 17:11:11: ValidateProductID. Rückgabewert 1.
    Aktion gestartet um 17:11:11: setUserProfileNT.
    Aktion beendet um 17:11:11: setUserProfileNT. Rückgabewert 1.
    Aktion gestartet um 17:11:11: setAllUsersProfile2K.
    Aktion beendet um 17:11:11: setAllUsersProfile2K. Rückgabewert 1.
    Aktion gestartet um 17:11:11: IsInstallElevated.
    Aktion beendet um 17:11:11: IsInstallElevated. Rückgabewert 1.
    Aktion gestartet um 17:11:11: CloseApps.
    Aktion beendet um 17:11:11: CloseApps. Rückgabewert 1.
    Aktion gestartet um 17:11:11: InitFileTypesOwner.
    Aktion beendet um 17:11:11: InitFileTypesOwner. Rückgabewert 1.
    Aktion gestartet um 17:11:11: SetRemove6xUpdates.
    Aktion beendet um 17:11:11: SetRemove6xUpdates. Rückgabewert 1.
    Aktion gestartet um 17:11:11: SetRemove7xUpdates.
    Aktion beendet um 17:11:11: SetRemove7xUpdates. Rückgabewert 1.
    Aktion gestartet um 17:11:11: CostInitialize.
    Aktion beendet um 17:11:11: CostInitialize. Rückgabewert 1.
    Aktion gestartet um 17:11:11: ResolveSource.
    Aktion beendet um 17:11:11: ResolveSource. Rückgabewert 1.
    Aktion gestartet um 17:11:11: ProcessAbcpy.
    Aktion beendet um 17:11:11: ProcessAbcpy. Rückgabewert 1.
    Aktion gestartet um 17:11:11: SetupPluginsProperties.
    Aktion beendet um 17:11:11: SetupPluginsProperties. Rückgabewert 1.
    [/code]

    Ich weiss, dass das was ich mir vorstelle nicht einfach zu erklären und schon gar nicht einfach zu realisieren ist und ich sicherlich
    mit meinen Fragen&Antworten wo möglich nerve aber ich mus halt genauer nachfragen weil es sich hierbei um die Veteilung der SW
    auf ca. 5000 Client handelt.

    Danke und Lg
    unlading-planet

    Freitag, 23. Juli 2010 07:32
  • Hallo unlading-planet,

    Installer, die im unattended/silent Modus GUI-Fehlermeldungen bringen, sollte man verbieten.

    Was hälts Du von einer Referenz-Installation für jedes SW-Produkt? D.h. ihr installiert das jeweilige Produkt testhalber und zeichnet ein "Installationsprofil" auf (Dauer, Muster Logdatei-Fehlermeldung, Muster Logdatei-Erfolgsmeldung etc.). Mit diesem Wissen konfiguriert ihr dann euer Verteilungstool, das würde Risikos m.E. minimieren. Klar dass man immer eine exit strategy haben muss. Nur so ein Gedanke.

    Marcel

    Freitag, 23. Juli 2010 08:07
    Moderator
  • Hallo U.,

    > > Die meisten Installationen werden heutzutage (zumindest unter der Haube) mit MSI-Technologie ausgeführt.
    >
    > Das gilt leider nur bei InstallShield ab Version 6.0.

    Es gilt für die meisten Installationen heutzutage. InstallShield kann das "auch", ja - meine Aussage gilt für alle Installer mit MSI Technologie.  Aber wie gesagt (wenn Du den Link durchliest), es ist dann nur mehr eine Sache der LOG-Aktivierung, die man über API, Registry o.ä. aktivieren kann, im Prinzip dann unabhängig vom Installer-Produkt - nur eben die Forderung MSI-Technologie.

     


    ciao Frank
    Freitag, 23. Juli 2010 08:08
  • @ Marcel Roma
    Dauer und Muster einer Installation wäre meines erachtens keine Lösung da die Installation von Appliktionen unterschieldich dauern könnte. Aufgrund verschiedee Computermodelle usw.
    Weiters könnte es vorkommen das beim installieren einer software, andere Software Bsp. JAVA, Oracle oder SQL-Server  als Vorraussetzung definiert ist. Diese könnte bei dem einen, durch die Installation einer anderen Software installiert sein und bei anderen nicht.
    Die installation aufzeichnen wäre ser aufwendig da die gleiche Software bei fast jeden Kunden anders installiert wird. Somit müsste man die glieche SW mehrmals aufzichnen und für den jeweiligen Kunden extra ablegen (Speicherplatz). Weiters müsste man, wenn ein Patch, PlugIn, Update usw. für eine SW rauskommt, das mehrfach warten.

    @ Frank Dzaebel
    Viele Installationen verweden zwar InstallShield aber bei allen ist es auch nicht möglich MS-Parameter mitzugeben. Und die fehlerausgabe ist von SW zu SW unterschiedlich. Ein 1703 Fehlercode würde bsp. bei einem Produkt darauf deuten das bsp. die Liznsdatei nicht gefunden wurde und bei einem anderen würde es bedeutet das administative Rechte fehlen. Viele Hersteller lassen sich die InstallWizzards selbt stricken bzw. schreiben ihren igenen Installer. Ich gebe dir vollkommen recht was MSI-WindowsInstaller betrifft aber es gibt doch eben genug andere, nicht alltägliche SW welche kein MSI oder InstallShild verwenden.

     

    Aber dane trotzdem für die tollen Antworten und
    Lg unlading-planet

    Freitag, 23. Juli 2010 10:43
  • Hallo U.,

    > Viele Installationen verweden zwar InstallShield ...

    ich spreche nicht von Installshield. Das warst Du.
    Ich spreche - jetzt wohl zum dritten Mal wiederholt - von Installern, die MSI Technologie benutzen [Punkt].


    > Und die Fehlerausgabe ist von SW zu SW unterschiedlich.

    und die Fehlerausgabe im MSI Log ist IMHO nicht unterschiedlich, bzw. die MSI-Fehlernummer sind auch klar definiert. Ich gebe Dir Recht bei Nicht-MSI-Installern, aber davon habe ich nie gesprochen. Wenn Du Nicht-MSI Installer benötigst, so sind meine Postinge hier irrelevant für Dich.

     


    ciao Frank
    Freitag, 23. Juli 2010 12:21
  • Halle Frank,
    ich merke schon das du bisschen gereizter bist.

    [QUOTE]
    Ich spreche - jetzt wohl zum dritten Mal wiederholt - von Installern, die MSI Technologie benutzen [Punkt].
    [/QUOTE]

    Ich kenne keine anderen Installer ausser InstallShield die MSI Technologien verwenden. Wen doch dann poste mal welche das sein könnten. Ich habe dich auch versanden. Bei MSI gibt s die errorcode und die entsprechend Meldungen aber da wären noch einpaar andere Tchnologien wie  z.B.:

    • Ghost Installer
      IExpress Setup
      Inno Setup
      NSIS
      Rundll-Parameter
      Wise Installer
      Windows Command Reference
      NOS-Installer
      DemoShield
      usw und so fort

    Lg
    unlading-planet

    Freitag, 23. Juli 2010 13:24
  • Hallo U.,

    es war wohl - weil ich mich das dritte mal wiederholen musste - aber gut, no prob.

    > Ich kenne keine anderen Installer ausser InstallShield die MSI Technologien
    > verwenden. Wen doch dann poste mal welche das sein könnten.

    Installer, die je nach Version MSI Technologie benutzen, sind zum Beispiel: 
    Visual Studio Setup's, InstallShield, Installaware, Wise Installer, Advanced Installer und WiX, Windows Installer Development Tools, und Tools wie: Lessmsi, MSI Factory, MakeMSI, Scriptomatic, MSI2XML and XML2MSI, Orca, etc. unterstützen da, um nur einige wenige zu nennen.
    (dabei nicht immer alle Versionen, und manche Tools verwendet man auch nur indirekt)
    Wie gesagt - die Mehrzahl nutzt eigentlich MSI.  (4 ;-)

     


    ciao Frank
    Freitag, 23. Juli 2010 13:49
  • Hallöchen,

    ich glaube wir reden bisserl aneinander vorbei. Nur weil die von dir genannten Installer MSI Technoligien verwenden heisst das nicht das sie auch wie MSI Installer arbeiten und die Logs auch genau so schreiben. In der Praxis sehen die Sachen meistens anders aus.
    [QUOTE]
    Ein 1703 Fehlercode würde bsp. bei einem Produkt darauf deuten das bsp. die Lizensdatei nicht gefunden wurde und bei einem anderen würde es bedeutet das administative Rechte fehlen
    [/QUOTE]

    Diese Art von Problemen gibt es mit Installern die MSI Technologien verwenden, leider.  Installaware und Wise Installer.

    habe ich aus dem Grund nicht erwähnt da diese wie InstallShield (iss) arbeiten. Mit Advanced Installer habe ich sehr sehr wenig zu tun gehabt. Windows Installer Tool, Orce, InstED etc. werden verwenden um die Parameter ausfindig zu machen und um evtl. MST Dateien zu erzeugen.
    WIX ist noch zu neu und ich habe noch keine Software welche diese Technologie verwendet gesehen.


    Ich glaube das es besser wäre den Thread zu schliessen da es anscheinend doch keine Möglichkeit gibt von verschiedenen Installer Technologien die Fehlercode mit den entsprechenden Fehlermeldung zu kommen. Es bringt auch nicht eine Datei mit allen möglichen Code zu erstellen un diese zu verwenden oder auch die Logdatei auszulesen. Da die Installation vielleicht erfolgeich ablaufen könnte aber ein Komponente nicht installiert wurde.

     

    Jedenfalls bedanke ich mich für das Brainstorming und wünsche noch ein schönes Wochenende.
    Lg unlading-planet

     


    Freitag, 23. Juli 2010 14:39
  • Hallo U.,

    > Nur weil die von dir genannten Installer MSI Technoligien verwenden
    > heisst das nicht das sie auch wie MSI Installer arbeiten und die Logs auch genau so schreiben.

    wenn jemand MSI verwendet, heisst das (doch schon), dass die MSI-Fehler damit in das MSI-Log geschrieben werden (wenn das aktiviert wird) und dort auch auslesbar sein wird. Deshalb haben (die Schweizer ;-) es auch erfunden - und deswegen sind u.a. auch Admins dankbar, das ihnen hier nachvollziehbare dokumentierte Fehler beschrieben werden.
    Und - um mich da nochmals zu wiederholen - es geht nur um Installer (Liste wurde gepostet / ggf. versionell unterschiedlich) die MSI auch während der Installation intern benutzen. Die meisten Installer benutzen heutzutage MSI Technik intern oder können das. 

    > Ein 1703 Fehlercode würde bsp. bei einem Produkt darauf deuten das bsp.
    > die Lizensdatei nicht gefunden wurde und bei einem anderen würde es
    > bedeutet das administative Rechte fehlen

    wie gesagt - ich wiederhole mich ja hier leider öfters - die MSI ErrorCodes sind spezifiziert:
    http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx

    Ein 1703 kann beispielsweise ge-customized werden. Dies geschieht dann aber wiederum auslesbar über die:

    [Error Table (Windows)]
    http://msdn.microsoft.com/en-us/library/aa368554(VS.85).aspx

    Nicht unnormal sind auch Produkte, die nicht ganz standardkonform arbeiten, aber das ist noch was anderes.

    > Ich glaube das es besser wäre den Thread zu schliessen ...

    no prob, ... nur schliessen tut man ansich nicht, indem man sein eigenes Posting als Antwort markiert, sondern ggf. einfach sagt, das man hier mal erstmal den Thread ruhen lassen möchte. Schliesslich ist für Dich hier anscheinend noch keine Antwort als hilfreich bewertet worden. 
    Ausserdem kann es sein, das später noch jemand kommt der vielleicht andere Infos hat, wobei Du Dir eine Antwort eines solchen Posters so ~ggf. unwahrscheinlicher machst.
    Aber gut - ich beende dann auch mal meine Postings zum Thema.
    Bis demnächst.


    ciao Frank
    Freitag, 23. Juli 2010 17:05