Fehlermeldung "Microsoft MSXML ist nicht installiert" bei Service-Anwendung

[KaiW]

Hallo zusammen,

ich erstelle aktuell mit Delphi XE7 unter Windows 7 eine Service-Anwendung, welche per REST XML-Daten mit einem Remote-Host austauscht. Den ganzen Ablauf und die entwickelten Klassen habe ich der besseren Fehler-Analysierbarkeit wegen vorher in einer "normalen" VCL-Anwendung getestet, alles lief bestens. Mein Service wirft jedoch nun die Fehlermeldung "Microsoft MSXML ist nicht installiert".
Ich nutze TXMLDocument in einer TMyServer-Klasse, abgeleitet von TObject.
Die zugehörige Variable FServer ist im private-Abschnitt des Services deklariert.
Die MyServer-Instanz wird im OnCreate des Service erzeugt.
Die Aufrufe der MyServer-Methoden erfolgen im OnExecute des Services in einer endlos-Schleife nebst Sleep(250) und ServiceThread.ProcessRequests(False);.

Bei der Lösungssuche habe ich hier im Forum den Artikel http://www.delphipraxis.net/177162-m...tcpserver.html
gefunden. Das dortige Problem scheint ähnlich, daher habe ich im Constructor des Service die Methode "CoInitialize(nil);" aufgerufen (unit ActiveX habe ich im implementation-Teil in die uses-Klausel aufgenommen).

Nach dem neu-Erzeugen (Build) des Services bekomme ich jedoch noch immer die gleiche Fehlermeldung.

Nach weitergehender Recherche bin ich auf den Artikel http://www.delphigroups.info/2/76/471694.html gestoßen. Es ist also möglich, dass es am Thread-Kontext liegt. Es wird u.a. empfohlen, Synchronize() aufzurufen.
Ich selbst erstelle im Service keinerlei Threads, kenne also nur den "ServiceThread", den mir Delphi im Service automatisch zur Verfügung stellt.
Angenommen, das ist der Hauptthread, dann darf ich synchronize daraus nicht aufrufen, da ansonsten eine Endlosschleife droht http://docwiki.embarcadero.com/Libra...ad.Synchronize
Zudem behauptet der Win7 Ressourcen-Monitor, der Service hätte 6-9 Threads.

Ich habe dann den Aufruf von "CoInitialize(nil);" in das OnExecute-Event des Services verlegt und verhindere über eine private Variable FInitialized, dass das ganze mehrfach aufgerufen wird.

Nun klappt es. Aber das Ganze erweckt bei mir den Anschein eines Work-arounds. Gibt es dazu Anmerkungen? Spricht etwas dagegen, es dabei zu belassen? Was ist mit dem Aufruf von CoUninitialize()? Wo packe ich den am besten hin, oder ist der letztenendes unnötig, da beim Beenden des Services eh alles automatisch resettet wird?

Gruß
Kai

[Der schöne Günther]

Hallo-

Ich habe nicht viel Ahnung von Diensten und ohne Code zu sehen wird das noch schwieriger. Ich würde aber raten dass dein Fehler hier steckt:

Zitat:

. Das dortige Problem scheint ähnlich, daher habe ich im Constructor des Service die Methode "CoInitialize(nil);" aufgerufen

Ohne es ausprobiert zu haben würde ich raten dass der Konstruktor des Service nicht in dem Thread-Kontext stattfindet in welchem er später läuft und seine Anforderungen entgegen nimmt. Vergleiche doch mit dem Debugger einfach mal welcher Thread es ist in welchem du CoInitialize aufrufst und welcher Thread es ist der dann die Exception wirft.


PS: Ich habe es grade einmal ausprobiert und habe keine Probleme damit:
- Im Service die Events OnStart und OnStop mit dem Starten und Beenden meines Hintergrund-Threads belegt
- Im "Execute()" meines Threads am Anfang einmal "CoInizialize" aufgerufen
- Dann wild mit XML hantiert
- Alles geht

PPS: Jepp, Das OnCreate-Ereignis ist ein anderer Thread-Kontext als OnStart. OnExecute wahrscheinlich genauso. Dein CoInitialize ist damit im OnCreate definitiv falsch. (Wofür ist OnExcute eigentlich gut? Ich nehme immer nur OnStart und OnStop und werde glücklich damit)

[Sir Rufo]

Das OnExecute ist im Prinzip das gleiche, wie das Execute beim Thread.

Ist OnExecute verdrahtet, dann wird ein Thread gestartet und dieses OnExecute vom Thread im Execute ausgeführt. (dient nur der Veranschaulichung)

Ich nehme allerdings auch immer separate Threads (oder eben nur einen) und kontrolliere den/dieses über die Events des Services.

Zur Frage selber:

Jeder Thread-Kontext der mit MSXML arbeiten möchte muss zwangsweise erst ein CoInitialize aufrufen, sonst geht da gar nichts (in diesem Thread-Kontext)