Open mnsrulz opened 1 year ago
Hi @mnsrulz Konsole cannot be used to render anything inside vscode debug terminal since the terminal does not support re-positioning output for printing. That being said, it should not throw an exception; and should not interfere with normal debugging. Please see attached screenshot showing debugging past the line you recieve an exception. Please provide more details (steps to reproduce) so that I can investigate further. regards, Alan
If you can share the output from dotnet --info
that will also be helpful. Please make sure you do not post any sensitive information most importantly environment variables that can contain secrets.
txs, A
Hi @mnsrulz Konsole cannot be used to render anything inside vscode debug terminal since the terminal does not support re-positioning output for printing. That being said, it should not throw an exception; and should not interfere with normal debugging. Please see attached screenshot showing debugging past the line you recieve an exception. Please provide more details (steps to reproduce) so that I can investigate further. regards, Alan
If you can share the output from
dotnet --info
that will also be helpful. Please make sure you do not post any sensitive information most importantly environment variables that can contain secrets. txs, A
Repro steps
//Program.cs
using Konsole;
try
{
var bar = new ProgressBar(10);
}
catch (System.Exception ex)
{
Console.WriteLine(ex.Message);
}
<!-- New folder.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<RootNamespace>New_folder</RootNamespace>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Goblinfactory.Konsole" Version="6.2.2" />
</ItemGroup>
</Project>
Start debugging by hitting F5 key and it will land in the catch block.
Here's the output of dotnet --info
PS C:\New folder> dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.104
Commit: 915d644e45
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.104\
Host (useful for support):
Version: 6.0.4
Commit: be98e88c76
.NET SDKs installed:
2.0.0 [C:\Program Files\dotnet\sdk]
2.1.817 [C:\Program Files\dotnet\sdk]
3.1.120 [C:\Program Files\dotnet\sdk]
3.1.401 [C:\Program Files\dotnet\sdk]
3.1.418 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.213 [C:\Program Files\dotnet\sdk]
5.0.402 [C:\Program Files\dotnet\sdk]
5.0.407 [C:\Program Files\dotnet\sdk]
6.0.100 [C:\Program Files\dotnet\sdk]
6.0.104 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.29 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.29 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Hi Again Thank you for the details, that is very helpful; apologies for slow replies, I'm just travelling out of the country at the moment and don't have access to my dev windows machine to test the above deeply. Could you please give me a copy of the stacktrace, that you get when it throws above, that could give some more insight, I have some ideas on how to protect agains this.
In the meantime I think I have found a possible workaround, described here; (unforunately I've not been able to test the suggestion) in the link below roblourens suggests using externalTerminal
in the launch.json, which if it does what it says makes sense would work around the problem
description here https://github.com/OmniSharp/omnisharp-vscode/issues/2336
If this works, then a good protection (code change I can include in next release) for konsole might work as follows, ...perhaps;
For step2 there is no practical way to keep track of all window and konsole commands and render anything useful to a debug console screen, so I think step 2 is a red-herring ..i.e. a no-go.
A better step 2 would be, if running in debug, and in vscode and an instance of Konsole window or control is created to throw a badOperation or better exception with error message,
konsole is not supported in vscode in debug mode without using `externalTerminal` in `launch.json`
Please update your `launch.json` (using link xyz) and restart your debugging session.
... and provide a link to a step by step notes on how to use that setting. (or include all instructions in error message if short is possible.)
A third option, that would require significant testing, and some non-trivial TDD testing would be to detect VSCode debugging as per 2 above, and disable rendering of the konsole window.
Unfortunately I dont have time at present to investigate option 3 without having access to a windows machine that reproduces the exceptions.
Hopefully the workaround of externalTerminal
will work for you?
best of luck,
regards
Alan
p.s. if you drop the stack trace I'll take a look at that, and if you can please let me know if externalTerminal works that will be very helpful, txs, A
Hi Again Thank you for the details, that is very helpful; apologies for slow replies, I'm just travelling out of the country at the moment and don't have access to my dev windows machine to test the above deeply. Could you please give me a copy of the stacktrace, that you get when it throws above, that could give some more insight, I have some ideas on how to protect agains this.
In the meantime I think I have found a possible workaround, described here; (unforunately I've not been able to test the suggestion) in the link below roblourens suggests using
externalTerminal
in the launch.json, which if it does what it says makes sense would work around the problemdescription here OmniSharp/omnisharp-vscode#2336
If this works, then a good protection (code change I can include in next release) for konsole might work as follows, ...perhaps;
1. when konsole instance first created, detect if running in debug mode, detect if running inside vscode 2. if true, then ignore cursor set position, though this presents the problem that a large amount of text (all refresh changes etc) for a progress bar will be rendered to debug output window,
For step2 there is no practical way to keep track of all window and konsole commands and render anything useful to a debug console screen, so I think step 2 is a red-herring ..i.e. a no-go.
A better step 2 would be, if running in debug, and in vscode and an instance of Konsole window or control is created to throw a badOperation or better exception with error message,
konsole is not supported in vscode in debug mode without using `externalTerminal` in `launch.json` Please update your `launch.json` (using link xyz) and restart your debugging session.
... and provide a link to a step by step notes on how to use that setting. (or include all instructions in error message if short is possible.)
A third option, that would require significant testing, and some non-trivial TDD testing would be to detect VSCode debugging as per 2 above, and disable rendering of the konsole window.
Unfortunately I dont have time at present to investigate option 3 without having access to a windows machine that reproduces the exceptions.
Hopefully the workaround of
externalTerminal
will work for you? best of luck, regards Alanp.s. if you drop the stack trace I'll take a look at that, and if you can please let me know if externalTerminal works that will be very helpful, txs, A
Yes the externalTerminal
works perfectly. Thanks for the suggestion.
Stack trace is as below for further analysis:
at System.ConsolePal.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)\r\n at System.ConsolePal.get_WindowWidth()
at System.Console.get_WindowWidth()
at Konsole.Writer.get_WindowWidth()
at Konsole.ProgressBarSlim.GetTextWidth(IConsole console, Nullable`1 width)
at Konsole.ProgressBarSlim..ctor(Int32 max, Nullable`1 textWidth, Char character, IConsole console)
at Konsole.ProgressBar..ctor(Int32 max, Nullable`1 textWidth, Char character, PbStyle style, IConsole console)
at Konsole.ProgressBar..ctor(Int32 max)
at Program.<Main>$(String[] args) in C:\\New folder\\Program.cs:line 6
Hi @mnsrulz I've updated the readme with instructions here and am closing this issue. Thank you for reporting and for your help. regards
Alan
I'm re-opening this issue (and tagging it with notAbug) so that the advice can be viewed by anyone else experiencing same issue.
The simple initialization of
ProgressBar
is throwing"The handle is invalid."
exception in VSCode while debugging.