Jak przechwycić dane wyjściowe śledzenia .NET z zadania Powershell?

Question

Używam NET w PowerShell, który wykorzystuje Trace.TraceWarning, Trace.TraceInformation itp

Chcę wyjścia te ślady do konsoli, gdy uruchomię mój skrypt PowerShell.

Działa to, gdy używam komponentu w bieżącej sesji. Na przykład (symulacja efektu śladowe) daje mi moc „cześć” do konsoli:

$listener = new-object "system.diagnostics.consoletracelistener" 
[System.Diagnostics.Trace]::Listeners.Add($listener) | Out-Null 
[System.Diagnostics.Trace]::TraceInformation("Hello") 

Ale jeśli zrobić to samo w pracy PowerShell dostaję żadnego wyjścia, choć ConsoleTraceListener należy pisać na standardowe wyjście, które z kolei spodziewałem się, że dostanę się do pracy. (Co ciekawe, Console.WriteLine nie działa również z zadaniem - ale robi to Write-Host).

zaczynam moją pracę tak:

$work = { 
    $listener = new-object "system.diagnostics.consoletracelistener" 
    [System.Diagnostics.Trace]::Listeners.Add($listener) | Out-Null 
    [System.Diagnostics.Trace]::TraceInformation("Hello") 
} 
$job = Start-Job -RunAs32 -ScriptBlock $work 
$job | Receive-Job -Wait 

Answer 1

Nie jest jasne, gdzie chcesz iść do niewoli wyjście. Większość dyskusji do tej pory dotyczy Konsoli, ale ponieważ nazwałaś to "pracą" (zakładam, że masz na myśli Zaplanowane Zadanie), nie jestem pewien, czy Konsola jest najlepszym miejscem. Nigdy nie zobaczysz wyników. Plik dziennika brzmi znacznie lepiej. W takim przypadku należy utworzyć TextWriteTraceLister. Umożliwi to ustawienie pliku dziennika dla wyników.

Dodatkowo jedną z ładnych funkcji Tracing w .Net jest możliwość dołączenia więcej niż jednego słuchacza. Jeśli więc chcesz zobaczyć dane wyjściowe podczas ich działania, możesz także dołączyć ConsoleTraceListener i nie będzie to kolidowało z zapisywaniem do pliku dziennika.

Wreszcie, istnieje również możliwość napisania własnego TraceListener. Jest to przydatne w takich sytuacjach, jak zapisywanie do bazy danych logowania lub usługi internetowej. Aby użyć własnego TraceListener z PowerShell, musisz zbudować detektor przy użyciu języka .Net, który może być skompilowany w bibliotekę klasy (dll), która może zostać wdrożona w GAC do użycia w twoim projekcie.

Answer 2

Pamiętam, że wpadłem na coś podobnego do tego z lat temu, kiedy oczekiwane STDOUT i STDIN nie zachowywały się zgodnie z oczekiwaniami przy starcie i exe. Skończyło się na użyciu System.Diagnostics.Process i przekierowanie STDIN i STDOUT. Oto przykład, który pokazuje to obejście w sposób, który może pomóc ci w tym, co próbujesz zrobić.

#added extra trace messages with Get-Date and implemented a random delay for demo purpose 
$work = { 
    $listener = new-object "system.diagnostics.consoletracelistener" 
    [System.Diagnostics.Trace]::Listeners.Add($listener) | Out-Null 
    1..10 | % { 
     Start-Sleep $(Get-Random 5) 
     [System.Diagnostics.Trace]::TraceInformation((Get-Date)) 
    } 
} 
#Create a process 
$process = New-Object System.Diagnostics.Process 
$process.StartInfo.UseShellExecute = $false 
#redirect stdout 
$process.StartInfo.RedirectStandardOutput = $true 
#call powershell 
$process.StartInfo.FileName = "powershell.exe" 
#pass the $work scriptblock 
$process.StartInfo.Arguments = "-noprofile -command $work" 
#start the process 
$process.Start() | Out-Null 
#readlines as they come in and exit when process is done 
while(-not $process.HasExited){ 
    $process.StandardOutput.ReadLine() 
} 

wyjściowa:

powershell.exe Information: 0 : 01/30/2015 12:27:17 
powershell.exe Information: 0 : 01/30/2015 12:27:20 
powershell.exe Information: 0 : 01/30/2015 12:27:21 
powershell.exe Information: 0 : 01/30/2015 12:27:25 
powershell.exe Information: 0 : 01/30/2015 12:27:26 
powershell.exe Information: 0 : 01/30/2015 12:27:28 
powershell.exe Information: 0 : 01/30/2015 12:27:29 
powershell.exe Information: 0 : 01/30/2015 12:27:33 
powershell.exe Information: 0 : 01/30/2015 12:27:36 
powershell.exe Information: 0 : 01/30/2015 12:27:40