No Debug mode is too visually similar to debug mode

[claudiaregio]

Describe the Issue

Hitting the "run project associated with this file" OR "run without debugging" from VS Code menu starts a debugging session instead of just running

Steps To Reproduce

1. Create a simple console app
2. Have Program.cs file open
3. Click "Run project associated with this file" in the menu in the top right

Expected Behavior

I would expect this to behave the same way as if I were in the project folder in the terminal and ran "dotnet run".

1. Project runs
2. No debug toolbar appears
3. Focus goes to "Terminal" not "Debug Console"

Environment Information

• Windows 11
• C# Dev Kit: v0.5.150
• C#: v2.5.30

[gregg-miskelly]

This bug is incorrect - we aren't debugging. However, VS Code makes almost no distinction in the UI between debugging and not debugging. The only way you can tell:

1. The pause button does nothing in 'noDebug' mode
2. In 'noDebug' mode, the .NET debugger will not print modules to the debug console

Related issues:

• Feature: Debugger should better handle Console.Read APIs with internalConsole dotnet/vscode-csharp#5704
• Terminal should always appear on top of the debug console when using integrated terminal dotnet/vscode-csharp#6516

[claudiaregio]

I wrote it under "expected behavior", but in case it helps, the expected experience is identical to what I'm seeing Python do here: https://code.visualstudio.com/docs/python/python-tutorial#_run-hello-world

[gregg-miskelly]

@claudiaregio Python has multiple ways to "Run without debugging". Some of their gestures just directly run the target script in the terminal, while others will use the VS Code APIs and would have the same problem as in this issue with there being very little distinction between run with and without debugging.

[gregg-miskelly]

I opened two more issues relating to this:

• Debugger should default to integratedTerminal when launching a console app without debugging #606
• 'Pause' command should be hidden or disabled when not debugging vscode#195417

I think once we have fixes for those two problems and dotnet/vscode-csharp#6516, this scenario should be much better. So I am closing this issue.