{"id":264,"date":"2014-12-01T00:01:00","date_gmt":"2014-12-01T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/12\/01\/provide-support-by-using-verbose-and-debug-streams\/"},"modified":"2019-02-18T10:36:50","modified_gmt":"2019-02-18T17:36:50","slug":"provide-support-by-using-verbose-and-debug-streams","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/provide-support-by-using-verbose-and-debug-streams\/","title":{"rendered":"Provide Support by Using Verbose and Debug Streams"},"content":{"rendered":"

Summary<\/b>: <\/span>Provide code support by using Verbose<\/strong> and Debug<\/strong> streams.<\/span><\/p>\n

Honorary Scripting Guy and Windows PowerShell MVP, Boe Prox, here today filling in for my good friend, The Scripting Guy. This is the first part in a series of five posts about troubleshooting Windows PowerShell scripts and functions. The series includes:<\/p>\n

    \n
  1. Provide Support by Using Verbose and Debug Streams <\/b>(this post)<\/li>\n
  2. Troubleshoot by Using Set-PSDebug<\/li>\n
  3. Enforce Better Script Practices by Using Set-StrictMode<\/li>\n
  4. Trace Your Commands by Using Trace-Command<\/li>\n
  5. Use the PowerShell Debugger<\/li>\n<\/ol>\n

    When you write a script or function, you want to make sure that things work correctly and that you have provided enough information for the individuals who will be using the code in their day-to-day activities. Although you have Get-Help<\/b> and inline comments in the code, sometimes they don’t provide the kind of troubleshooting that is needed when you are not getting the results that you are expecting.<\/p>\n

    We need a way to provide on-screen information that can be turned on or off without much more than a simple parameter. If only we had some sort of Verbose<\/b> or Debug<\/b> capability that could make this happen…<\/p>\n

    Oh, wait!<\/p>\n

    We have this built-in with Windows PowerShell!<\/p>\n

    Whenever a script or function is being built, all we have to do is add a couple of lines at the beginning of the code block to enable the Verbose<\/b> and Debug<\/b> parameters. As shown here, those pieces are [cmdletbinding()]<\/b> and Param()<\/b>:<\/p>\n

    [cmdletbinding()]<\/p>\n

    Param ()<\/p>\n

    \"Image<\/a><\/p>\n

    You must<\/b> have these attributes available to have this capability. After this is accomplished, you can use Write-Verbose<\/b> and Write-Debug<\/b> in your code to provide more information when the script runs. Of course, you could use Write-Host<\/b>, but that doesn’t turn off unless you provide your own parameter (a switch) and then use some logic to run the command if the parameter is used.<\/p>\n

    Using Verbose<\/b> and Debug<\/b> provides a cleaner approach to providing output by having a single line (Write-Verbose or Write-Debug) that provides information to the users (or to yourself) when someone is attempting to figure out why a script isn’t running the way it should. Another great feature that was introduced in Windows PowerShell 3.0 is that you can redirect the streams to a file if needed.<\/p>\n

    Note <\/b> June Blender wrote an excellent post that you can read for more information: Understanding Streams, Redirection, and Write-Host in PowerShell<\/a>.<\/p>\n

    So how should I use Write-Verbose<\/b> and Write-Debug<\/b>? In the end, it depends on what you want to use them for. In my case, I use them in the following ways:<\/p>\n