Ich habe einen Fall gefunden, in dem dieselbe Batch-Datei anders funktioniert als die Befehlszeile und wenn sie von einem WCF-Service ausgelöst wird, der auf IIS gehostet wird. Der Unterschied liegt im XCOPY-Befehl. Wenn ich die Batchdatei normal ausführe, verschiebt XCOPY alle Daten, die ich brauche
%Vor%Wenn es jedoch vom WCF-Dienst ausgeführt wird, wird nichts kopiert. Zum Ausführen des Stapels von meinem Dienst verwende ich den folgenden Code Batch-Datei in C # ausführen mit ein paar kleinen Modifikationen. Meine Anwendung pull läuft unter LocalSystem account. Ich habe auch versucht, mein eigenes Konto für die Umfrage zu verwenden - funktioniert nicht. Was ist los?
Kurzes Update: Was ich in letzter Zeit gelernt habe, ist, dass mein WCF-Dienst unter dem App-Pool-Benutzer ausgeführt wird, der Prozess jedoch nicht. Zum Zweck des Experiments habe ich ein Update in den Prozess-Start-Code
gemacht %Vor%aber es hilft nicht. Es scheint, dass es einen Mystiker gibt, XCOPY unter den beschriebenen Bedingungen zu betreiben.
Noch ein Update: Dasselbe Problem mit XCopy wird auch in einem Prozess gefunden, der unter einem regulären Windows-Dienst gestartet wird.
Verwaltet, um mein Problem durch diesen Beitrag zu lösen ( Ссылка ) Also eigentlich ist die Antwort:
%Vor%Dies ist eine Eigenart von xcopy.exe. Wenn Sie die Ausgabe umleiten, müssen Sie Umleitung der Eingabe auch.
Sie können den ASP.NET-Kompatibilitätsmodus verwenden, damit der WCF-Dienst einen bestimmten Benutzer imitiert. Dies erfordert nicht, dass Ihr AppPool unter diesem Benutzer ausgeführt wird.
Es gibt 3 Schritte:
Aktivieren Sie den ASP.NET-Kompatibilitätsmodus
%Vor%Konfigurieren Sie Ihren Dienst für die Verwendung des ASP.NET-Kompatibilitätsmodus
%Vor%und konfigurieren Sie den ASP.NET-Identitätswechsel zum Annehmen der Identität eines Benutzers
%Vor%Haben Sie versucht, die Identität des Anwendungspools unter einem benutzerdefinierten Domänenkonto auszuführen? Als Test können Sie versuchen, Ihr eigenes Konto zu verwenden, obwohl ich nicht empfehlen würde, das auf lange Sicht zu verwenden, da das Entschlüsseln von Kennwörtern in IIS-App-Pools trivial ist und Sie es jedes Mal ändern müssen, wenn Sie Ihr eigenes Konto ändern Passwort.
Microsoft sagt in den IIS-Sicherheitsempfehlungen ( Ссылка ), dass eine benutzerdefinierte verwendet wird Domänenaccount ist akzeptabel:
Blockquote Die Verwendung eines benutzerdefinierten Identitätskontos ist akzeptabel, aber stellen Sie sicher, dass Sie für jeden Anwendungspool ein anderes Konto verwenden.
Aus Sicherheitsgründen ist die Standard-ApplicationPoolIdentity ziemlich gesperrt, diese KB verweist auf ein anderes Problem, sollte aber eine Vorstellung von den Problemen geben, die auftreten können, wenn Sie damit umgehen: Ссылка
Ich hoffe, du nimmst es nicht als unbegründete Kritik, aber du hättest uns wahrscheinlich alle wichtigen Codeschnipsel zeigen sollen. Der spezifische Grund in diesem Fall ist, dass wenn Sie einen Prozess aufrufen, ist es in der Regel eine sehr gute Idee, den Exit-Status zu erhalten, aber ich bin mir nicht sicher, ob Sie es tun oder nicht. Der Exit-Status kann uns einen Hinweis darauf geben, was vor sich geht.
Last but not least sind Process Monitor und Process Explorer von Microsoft Sysinternals großartige Werkzeuge, um diese Problemklasse zu untersuchen. Wenn das Ändern der Anwendungspoolidentität auf ein benutzerdefiniertes Domänenkonto das Problem nicht feststellt, würde ich diese verwenden um nach weiteren Hinweisen zu suchen.
Einige Referenzen zu verwalteten Dienstkonten
Tags und Links wcf c# windows-services iis-7 xcopy