Add support for Write-Progress cmdlet

[HairyCream]

The following code, when executed using the debugger, will show the Write-Host output, but not the Write-Progress output.
for ($i = 1; $i -le 10; $i++ ) {write-progress -activity "Search in Progress" -status "$i% Complete:" -percentcomplete $i; Write-Host "Seconds Passed: " $i; Start-Sleep 1}

[daviwil]

Thanks for filing this. I'll have to see if there's a reasonable way to show progress in VS Code other than just writing progress lines to the console text.

[thoughtentity]

One possible thought for showing progress for long running PowerShell operations would be to pipe Write-Progress message as status bar messages in VS Code. I believe the API was designed to show ephemeral messages as it supports automatically expiring messages based on a timeout or Disposable. VS Code also uses the status bar area to show long running git operations (spinning icon during git push and pull).

[rkeithhill]

That thought occurred to me as well. One issue is that Write-Progress can support up to three separate strings that should all be displayed: Activity, Status and CurrentOperation in addition to a percent complete value. Another issue is that Write-Progress supports multiple active, potentially nested progress bars.

Maybe the extension needs to create a UI for progress records kind of like ISE does where the UI is display at the top of the console pane. Not sure if that is possible with VSCode.

[daviwil]

Yeah, we currently don't have the ability to create custom UI in VS Code. @thoughtentity's idea is a good one, but like Keith says, PowerShell progress bars can get pretty complex so the status bar might not be the best place to represent that. We'll have to look for a creative solution for showing progress in more complex scenarios.

[ChrisLynchHPE]

Looking forward to this feature. I have a number of build scripts that I use Write-Progress and currently with 0.10.0 am unable to see the output from. If I use the integrated console (powershell.exe) separately from the vscode-powershell plugin 'Integrated PowerShell Console', Write-Progress does output, and very well I might add.

[daviwil]

Yep, I've basically written my own ConsoleHost so I have to implement my own version of Write-Progress in this case. I'll probably try to borrow the implementation from PowerShell Core which isn't as pretty but gets the job done.

[andysimmons]

I don't know if it'll handle the complexity of PS progress bars yet, but there are some new APIs in the latest (1.12.1) VS Code release that might be interesting.

https://code.visualstudio.com/updates/v1_12#_extension-authoring

Awesome extension, by the way.

[daviwil]

Thanks Andy! Yep, I've considered using that but not sure if it will be a good UX. I'll experiment with it pretty soon :)

[stephenbonar]

Version 1.0 seems much more stable than the pre-release versions, I find myself using the PowerShell ISE less and less! I'm definitely looking forward to Write-Progress functioning in the integrated console, but until then, I at least have the workaround of adding a powershell.exe console in the integrated terminal, which still shows progress.

[crshnbrn66]

I too have been using VScode more and more and less and less ISE.

[daviwil]

I've got an idea on how I might be able to reuse PowerShell's existing progress display, will experiment with this a bit and hopefully get it working in 1.3 or 1.4.

[tmknight]

HI, any update to this highly anticipated enhancement?

[jmiller76]

https://github.com/gravejester/psInlineProgress
or
Install-Module -Name psInlineProgress -Scope "CurrentUser"

This works if you tweak line 110 in the PSM1 to bypass the detection of the ISE. Also a tweak in the psd1. (I just copied the functions over and ran)
CC: @gravejester

[FireInWinter]

This is a big issue for me. I have a lot of scripts that can take hours to run, but show the progress through Write-Progress. Without it, I have no way of seeing what it is doing without modifying a lot of code. Could we please get something even if it isn't a perfectly good UX? Having something that sort of works and is ugly is better than nothing.

I also don't understand why the default console (powershell.exe) handles it just fine. Why not implement that for now until a better looking solution is available?

[thoughtentity]

The current VS Code release v1.15.1 has built in support for the Write-Progress cmdlet in the regular integrated shell however the progress UI will not show up if you're using the integrated shell provided by VS Code PowerShell extension.

[tmknight]

Confirmed! Either execute your dotted script in 'powershell' host (not powershell integrated) or copy and paste code into 'powershell'.

Else use https://github.com/gravejester/psInlineProgress. Be sure to REM Line 36 of the psd1 - the psm1 already does a check for $Host.Name -notlike '*ISE*':
# Name of the Windows PowerShell host required by this module
#PowerShellHostName = 'ConsoleHost'

[JustinGrote]

I like @SeeminglyScience's thought, if it actually works.

Alternatively could just capture the progress stream and send it to the VSCode Progress API. Maybe have an option toggle

Here's one way to do that.
https://github.com/Microsoft/vscode-extension-samples/tree/master/progress-sample
$pscmd = [Powershell]::Create();$pscmd.AddScript({1..100 | % { Write-Progress -Activity "Test" -Status "Processing $_"}}).Invoke();$pscmd.streams.progress

[XzipbitA]

If you would like to make it work in both windows:

$data=1,2,3,4,5,6,7,8,9,10;for ($i = 1; $i -le $data.length; $i++ ) {write-progress -activity "Search in Progress" -percentComplete ($i/$data.length*100);Write-Host -NoNewLine "`rProgress: $($i/$data.length*100)%";Start-Sleep -Milliseconds 100;};Write-Host("`n"); 

[ajacks88]

Would be great if this could be supported in some way in vscode. Currently it is the only thing i do in ISE that i cannot do in vscode.

[potatoqualitee]

Would really love to see some progress here. I'd like to use VS Code on Windows for my presentations but need Write-Progress because it offers pizzazz that delights audiences. I tried to compromise with VS Code on my Mac but the commands I'm running are not supported in VS Code because they use Cim.

[tmknight]

This is likely very low priority. I've moved on with a module I wrote (liberating the best bits from psInlineProgress). Maybe it will help others...

[JustinGrote]

I'm currently using a proxy command for write-progress in my vscode profile as a wrapper for write-in line progress as well. This is certainly "fixable" and could be tied from the editor services into the progress messaging API in Vscode. I might give it a proof of concept shot in my spare time but I know very little typescript so it'd probably be poor quality and not up to pull request standards.

…

On Mon, Feb 25, 2019, 7:49 AM Travis M Knight ***@***.***> wrote: This is likely very low priority. I've moved on with a module I wrote <https://github.com/tmknight/Write-InlineProgress> (liberating the best bits from psInlineProgress <https://github.com/gravejester/psInlineProgress>) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOjVUoGPlTmx4zbA8Ip3ks1umRNWZbqWks5vRAYEgaJpZM4IHNag> .

[TylerLeonhardt]

We hear you all! Thank you so much for commenting. It's useful to build our prioritization. @rjmholt and I have been tied down on other things - Rob's been working on some Script Analyzer work and I've been working on a few things in PowerShell to make debugging better in the extension.

That said, I'll bring this feedback to @SteveL-MSFT so we can prioritize it higher.

Thank you all for understanding!

Also, @JustinGrote if you want to try to fix this, please give it a shot! We are happy to work with you to get something in. 😊

[JustinGrote]

Here is the code sample for the progress api:
https://github.com/Microsoft/vscode-extension-samples/tree/master/progress-sample

If I get a half-decent working model together I'll PR it.

[TylerLeonhardt]

The other solution we were thinking about was taking the code from the Progress API in PowerShell Core and adding it to PowerShell Editor Services which has its own host.

This would align the host in PowerShell Editor Services, with the regular Console Host in PowerShell Core.

[JustinGrote]

So I assume at this point that the PSES host isn't even capturing the progress stream, so that's gonna need to be done first. I tried capturing the named pipe between PSES and the vscode extension but it breaks every time I do so I can't see if the JSON actually contains the progress output or not.

Assuming not, seems what needs to be done is:

1. I run "write-progress test" and that goes to PSES which executes it in the runspace
2. Capture the progress stream in PSES (by taking Powershell Core's API or whatever)
3. Send the progress stream results over the PSES -> VSCode pipe
4. Either output directly in the integrated console, or use the vscode withProgress function to display it (maybe have a toggle settings for either for those who have a preference).

1-3 are C# activities in PSES and I think I'm out of my depth there unfortunately :(

Only thing I think I can contribute is maybe a wrapper function around write-progress that calls the withProgress API of VSCode directly and bypasses going to PSES and back. Not the most elegant solution but workable until a more robust solution in the PSES host can be devised.

[SeeminglyScience]

I hesitate to recommend trying to fit this into the VSCode UI. There's a few major obstacles:

1. Write-Progress can be incredibly complex, displaying progress for multiple activities at once
2. Every single ProgressRecord would have to be sent over a named pipe to VSCode
3. Our messaging queue already has issues keeping up
4. Since it doesn't happen synchronously with the pipeline, some scenarios would lead to a lot of lag between updates (while the command actually continues progressing)

I'm not saying we should never hook it up to the UI, but I'd suggest holding off until some heavy investment into our messaging queue has been made.

I still think the best bet is to reuse the existing ConsoleHost. I tested it, it does work. The problem is that since ConsoleHost isn't the one creating pipelines, it isn't cleaning up progress messages after each pipeline invocation. There's a few options

1. Keep track of the progress messages we send to ConsoleHost and send clean up progress messages for any that the user did not. This would be my suggestion (assuming it works)
2. Use reflection to access the clean up method on ConsoleHost. This would be an easy pick but it's behind several layers of obtuse to access internal API's. This would be very fragile
3. Copy the Write-Progress implementation from the PowerShell repo. This is my least favorite as we would miss improvements made upstream. Also if PowerShell ever drastically changes how their progress looks, it would be the same in PSES for both Core and Windows PowerShell.

[JustinGrote]

Being far from the expert in this area I defer to Patrick. :)

…

On Mon, Feb 25, 2019, 7:30 PM Patrick Meinecke ***@***.***> wrote: I hesitate to recommend trying to fit this into the VSCode UI. There's a few major obstacles: 1. Write-Progress can be incredibly complex, displaying progress for multiple activities at once 2. Every single ProgressRecord would have to be sent over a named pipe to VSCode 3. Our messaging queue already has issues keeping up 4. Since it doesn't happen synchronously with the pipeline, some scenarios would lead to a lot of lag between updates I'm not saying we should never hook it up to the UI, but I'd suggest holding off until some heavy investment into our messaging queue has been made. I still think the best bet is to reuse the existing ConsoleHost. I tested it, it *does* work. The problem is that since ConsoleHost isn't the one creating pipelines, it isn't cleaning up progress messages after each pipeline invocation. There's a few options 1. Keep track of the progress messages we send to ConsoleHost and send clean up progress messages for any that the user did not. This would be my suggestion (assuming it works) 2. Use reflection to access the clean up method on ConsoleHost. This would be an easy pick but it's behind several layers of obtuse to access internal API's. This would be very fragile 3. Copy the Write-Progress implementation from the PowerShell repo. This is my least favorite as we would miss improvements made upstream. Also if PowerShell ever drastically changes how their progress looks, it would be the same in PSES for both Core and Windows PowerShell. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOjVUmAqVMCP42nlMP-JI3ImlUnRYuVKks5vRKpUgaJpZM4IHNag> .

[FireInWinter]

@SeeminglyScience I also think avoiding the VSCode UI for now is preferred. From what others have said, it doesn't really have all the features to support Write-Progress currently.
I think the ConsoleHost option would probably work, it seems anything done that way would involve some fragility/complexity. I would actually suggest copying Write-Progress from the PowerShell repo as a good solution. Yes, it wouldn't be in sync with PowerShell Core, but if it is ever implemented to use the VSCode UI, it won't be in sync anyway. But I think whichever way gives us the full cmdlet capabilities the quickest, is the best solution in the short/medium term. When it is switched to use the VSCode UI, it shouldn't happen until it can be fully supported.

[SeeminglyScience]

@FireInWinter

But I think whichever way gives us the full cmdlet capabilities the quickest

The fastest would be suggestion 1, assuming it works. "Copying" was probably the wrong term to use, "porting" is a bit closer. There is a chance that the implementation in core would work with minimal changes, but differences between targeting netcoreapp and netstandard are often non-trivial.

Yes, it wouldn't be in sync with PowerShell Core

My hesitation is more the other way around. We would want to keep it in sync with core, so if the implementation in core ever changes drastically, those folks who are still on Windows PowerShell would get a very different experience.

but if it is ever implemented to use the VSCode UI, it won't be in sync anyway.

Honestly this is another reason why I believe a console implementation is preferred. My opinion is that the integrated console should strive to be as close as possible to a normal PowerShell console for consistency. It's a lot easier to debug/test a script when you aren't worrying about whether the problem is the editors specific host implementation.

[rkeithhill]

Potential solution happening here in VSCode - microsoft/vscode-languageserver-node#261

[TylerLeonhardt]

Write-Progress support in the Console has been added in the PowerShell Preview extension!

[JustinGrote]

Saw that go up today and it works great! So far no issues, well done.

[SydneyhSmith]

Closing as this is available in the Preview extension and would be substantial and possibly destructive change to backport to 1.x

[rjmholt]

Additionally, when we did the technical evaluation of this, the implementation of the Write-Progress API in the preview version was very different from what 1.x would require. In an attempt to stabilise the 1.x branch, we've tried to raise the bar on risky additions, and we didn't feel we could justify the possible breakage.