PowerGUI® Pro and PowerGUI 2.2 are now available

Posted on by Kirk Munro

I just finished releasing the bits for PowerGUI Pro 2.2 and PowerGUI 2.2 to the web.  This release contains some really useful updates to PowerGUI, most notably a new debugging engine based on the native PowerShell 2.0 debugger.  This allows you to do take advantage of all of the debugging functionality in PowerShell 2.0, including support for:

  • The Disable-PSBreakpoint, Enable-PSBreakpoint, Get-PSBreakpoint, Remove-PSBreakpoint and Set-PSBreakpoint cmdlets;
  • Command and variable breakpoints;
  • $MyInvocation;
  • and more

For basic debugging support of a single script file you might not notice a difference right away, but if you do anything beyond basic scripting the new debugging engine will be a welcome change.  It allows you to set breakpoints in a module that you have loaded or a script file that you have dot sourced, and the debugger will open the file with the breakpoint if it is not already open and stop on the breakpoint when the breakpoint is hit.  It also allows you to debug module scripts themselves by setting a breakpoint within a module psm1 file and loading the module using the Import-Module cmdlet from the embedded PowerShell Console.  Breakpoints are retained between sessions as well, so that you can pick up where you left off day after day.

In addition to the debugger changes, there are a number of useful bugfixes included in this release such as improved compatibility between the PowerGUI Script Editor and the Quest AD cmdlets when using STA mode (the default), proper $MyInvocation support in scripts, and other fixes that allow Start-Job and Invoke-Command to be used in scripts that are run through the debugger.

To get the latest release, if you are a PowerGUI Pro customer you can visit SupportLink to get the most recent version or if you use the freeware version you can visit the PowerGUI Downloads page and download and install the release from there.  Alternatively, for both PowerGUI Pro and PowerGUI freeware you can simply wait until auto-update kicks in and prompts you to upgrade (auto-update checks for a new version once per day, the first time you open the product each day), or you can use the Help | Check for Updates menu item in the Admin Console or Script Editor to check for updates without waiting for the next time it checks automatically.

Note to 2.2 public beta testers: if you were participating in the PowerGUI 2.2 public beta, and if you upgraded your beta install to the release candidate when we had posted it, then you already have the RTM version of PowerGUI.  We collected feedback during the release candidate stage and did our own internal testing and the release candidate was solid enough that we were able to leave it as is.  This means that you don’t have to do anything to upgrade to the 2.2 release in this case.

As always, if you have questions, comments, concerns, we’re always listening.  Please let us know what you think of the new capabilities that are introduced with the new debugging engine!

Kirk out.

15 thoughts on “PowerGUI® Pro and PowerGUI 2.2 are now available”

  2. Just got the update, and now any breakpoint I set in the script editor, using the GUI (F9 or click in the margin) is skipped. I’ve been beating my head on this for an hour now, trying to figure out how to get a simple breakpoint to work the way it used to.

    Any ideas? I’m running on Win7 x64. The prior version worked OK.

  3. I just posted a comment saying that setting breakpoints in the GUI via F9 or the left margin doesn’t work with the new version. I am pretty sure I’ve isolated the problem.

    Open a new window, type some code, set a breakpoint. Hit F5. Works (hits breakpoint).

    Save it to c:\temp. Hit F5. Works.

    Save it to a directory containing square brackets in the name such as c:\temp\[mysubdir]. Hit F5. DOES NOT STOP at any breakpoint.

    The standard at my company is to use directory names with brackets for all directories tied to source control…so that’s where all the scripts I work on are…so this problem was really vexing until I figured it out. Not sure what I’ll do.

    I’m obviously a minority but if this can be fixed it would be really cool!

    1. Hi Glen,

      Thanks for reporting this issue. We did a lot of work in the debugger in this release to support the native debugging capabilities in PowerShell 2.0. This was required to get advanced breakpoint support as well as to fix issues with $MyInvocation, Start-Job and Invoke-Command when debugging scripts. From what you have reported, it sounds like we may have run into a new issue with that change. I’m not sure at this time if that issue lies with the native PowerShell debugger or if it lies with PowerGUI’s implementation of support for that debugger. I have passed your question on to the development manager to get his insight and I will respond back once I hear from him, which should be early next week. Note that we have the previous version posted on http://www.powergui.org/entry.jspa?externalID=2192, so you can revert to that version if this is a really big issue for you until we work something out. Anyhow, if you can sit tight for now though, wait until I hear back from dev early next week please. Thanks!

      Kirk out.

  4. Hello,

    Trying to install on Windows 2008 R2 with .Net 4 installed. Installer says it needs .Net 3.5. Framework. Is 3.5 specifically neccesairy or is there a check that could be altered to if .Net =>3.5 then continue

    Many thanks, and thanks for an excellent usefull program

    Martin

    1. I believe .NET 3.5 is specifically necessary, but I’ll check with development to make sure. Thanks for the feedback!

    1. You’re right Glen, it is a general PowerShell issue. There is good news though! The PowerGUI project manager confirmed that since we call Set-PSBreakpoint internally when you use the UI to set a breakpoint, we can fix this issue in the next release because we can add specific support for paths with square brackets in their names! Also, if you don’t want to wait and you don’t want to downgrade PowerGUI, you could create an Add-on to work around the issue today! And even better, you could enter that Add-on into the PowerGUI Challenge contest! 😉

      If you want more details about any of this, let me know.

      1. Thanks, Kirk. It drove me nuts until I figured out the cause. For now I threw my organization’s convention to the wind and changed my workspace. No brackets, no problem. And with that out of the way, I can say that this is a very nice release! Keep up the great work on a great product! I recommend it to anyone who asks me about Powershell.

  7. ISSUE: PSM1 files (modules) do not execute anymore when opening it in the editor and cannot be runned or debugged.
    The previous PowerGUI executed the PSM1 when opening and I could easily set breakpoints, run an debug.

    1. Hi Victor,

      You can still set breakpoints and debug modules, although the method used to do this may have changed slightly from what you are used to. To debug a module, do the following:

      1. Open the psm1 file you want to debug.
      2. Set a breakpoint in the psm1 file.
      3. In the embedded PowerShell Console, invoke the following command: Import-Module moduleName, where moduleName is the name of the module you want to debug.

      When you do this, PowerGUI will stop on the breakpoint in your module and allow you to debug it.

      It would be helpful for me if you could share the steps you used to take to debug modules in the previous version of PowerGUI so that I can see if we can support those same steps in a future version as well. Moving to the new debugger was a necessary step we had to take, and I’m not surprised that there are a few minor bumps in the road as a result. We will be working to resolve those issues as much as possible, so be sure to let us know the details so that we can evaluate the issue and see what we can do.

      Thanks for the feedback!

      Kirk out.

      1. Hi Kirk,

        These are the steps I took:
        1. I start the Script Editor. It’ll load all the script files that were open when I closed the editor. One of the files is the module. The file for this module is not in the regular module path, but in my working directory with accompanying ps scripts.

        2. When opening module file, the editor somehow runs the module code (I see its output in the output window of the editor).

        3. When editing and debugging changes in the module file, I just set a breakpoint and press F5 to start debugging.

        I’m tempted to go back a version of PowerGUI. I’ll try you debugging tip first.

        How can I load the module into the Editor’s powershell session in order to debug other dependent scripts?
        I don’t want to copy the module to a module path.

      2. Hi Victor,

        Thanks for the details. PowerGUI remembers which modules were loaded between sessions, which is why you would see the output from your module each time you start the Script Editor. You need to specifically unload a module using Remove-Module or the File | PowerShell Libraries dialog if you want to unload a module and not have it loaded in the next session. When you would press F5 to debug your module, I suspect it wasn’t being loaded as a module at all but instead it was being run as a script. That is not what you really want to be doing. Using Import-Module from the embedded PowerShell Console to debug is the right way to go in this case. Just don’t forget to either use the -Force parameter to force the module to be reloaded or to call Remove-Module first to unload your module. Otherwise PowerShell will detect it is already loaded and not invoke the contents.

        I can see how pressing F5 when you have a module script file open would be convenient and intuitive, so I’m going to discuss this with the team.

        I think you should stick with the current version of PowerGUI. For module debugging, it is a much better solution. For example, you can set breakpoints in functions declared in script files that you have dot-sourced or in module files that you have loaded and when you invoke a command interactively in the embedded PowerShell Console or through one of your scripts, those breakpoints will be hit. Or you can use Set-PSBreakpoint to set command breakpoints and hit them regardless of where the command is called. The new debugger is much more powerful than the old debugger, and although it is not perfect yet it is definitely a step in the right direction. If you want to debug something that you are going to load, all you need to do is set the breakpoint in the appropriate file or for the appropriate command and then debug a script or invoke commands interactively and you should be good to go. Let me know if you need more clarification about how this can work.

        Thanks,

        Kirk out.

Leave a comment