Powershell: Debug output with line numbers/stack

[SteveL-MSFT]

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'

[ThomasNieto]

This sounds more like debug rather than verbose. The end user wouldn't get any benefit if they saw that information. End users are the primary target for verbose messages.

[vexx32]

I would agree with that. This is likely to be a better fit for -Debug, and actually a great way to distinguish use of -Debug from -Verbose now that the default DebugPreference when using -Debug is now Continue.

[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.)

[SteveL-MSFT]

I think that's the basic problem, even the PowerShell team doesn't use write-debug. Updating title to reflect this should be for write-debug. Getting people to use that cmdlet is a separate issue.

[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.