Debug output with line numbers/stack

Summary of the new feature/enhancement

This is primarily for scripts, but could work with binary modules. Often I use Verbose output to help diagnose why something isn’t working (like our build.psm1 module). It would be very helpful if Verbose output also wrote out the script file and line number.

This was originally for Write-Verbose because that’s what the PowerShell Team uses for their scripts, but we should figure out why people aren’t using Write-Debug.

Proposed technical implementation details (optional)

Possibly add a new VerbosePreference of “ContinueIncludeCallSite”

Current example output:

DEBUG: Using configuration 'Debug'
DEBUG: Using framework 'netcoreapp3.1'
DEBUG: Using runtime 'win7-x64'
DEBUG: Top project directory is D:\PowerShell\src\powershell-win-core
Run dotnet restore D:\PowerShell\test\tools\Modules --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet
Done restoring D:\PowerShell\test\tools\Modules
Name='SelfSignedCertificate', Version='0.0.4', Destination='D:\PowerShell/test/tools/Modules'
DEBUG: $env:POWERSHELL_TELEMETRY_OPTOUT = 'yes';$env:PSModulePath = 'D:\PowerShell\test\tools\Modules;'+$env:PSModulePath;Set-ExecutionPolicy -Scope Process Unrestricted; Import-Module 'D:\PowerShell\src\powershell-win-core\bin\Debug\netcoreapp3.1\win7-x64\publish\Modules\Pester'; Invoke-Pester -OutputFormat NUnitXml -OutputFile C:\Users\slee\test\pester2.xml -ExcludeTag @('Slow') -Tag @('CI','Feature') 'D:\PowerShell\test'

proposed opton (line numbers made up):

DEBUG: (@ .../build.psm1:30) Using configuration 'Debug'
DEBUG: (@ .../build.psm1:31) Using framework 'netcoreapp3.1'
DEBUG: (@ .../build.psm1:32) Using runtime 'win7-x64'
DEBUG: (@ .../build.psm1:38) Top project directory is D:\PowerShell\src\powershell-win-core
Run dotnet restore D:\PowerShell\test\tools\Modules --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet
Done restoring D:\PowerShell\test\tools\Modules
Name='SelfSignedCertificate', Version='0.0.4', Destination='D:\PowerShell/test/tools/Modules'
DEBUG: (@ .../build.psm1:115) $env:POWERSHELL_TELEMETRY_OPTOUT = 'yes';$env:PSModulePath = 'D:\PowerShell\test\tools\Modules;'+$env:PSModulePath;Set-ExecutionPolicy -Scope Process Unrestricted; Import-Module 'D:\PowerShell\src\powershell-win-core\bin\Debug\netcoreapp3.1\win7-x64\publish\Modules\Pester'; Invoke-Pester -OutputFormat NUnitXml -OutputFile C:\Users\slee\test\pester2.xml -ExcludeTag @('Slow') -Tag @('CI','Feature') 'D:\PowerShell\test'

[rkeithhill]

I’ve avoided Write-Debug because it paused execution. That always seemed like a conflation of concerns to me. I really wanted Write-Debug to just write to the debug stream. Guess that works as expected now. I need to try that, having flipped the bozo bit on Write-Debug years ago. 😃

Having the extra data (file:line:col) on debug stream messages would be nice.

[BrucePay]

The Verbose stream is for the end-user of a command. It’s intended to provide additional information about how the command is proceeding but isn’t intended to be a debugging stream for the developer of the command. As the others have observed, that’s what the Debug stream is for. Now historically I don’t believe Debug has been used very much. Perhaps we should encourage it’s use a bit more (and obviously make sure it works the way users expect.)