We are pleased to announce PowerShell Plus 5.0 is now available for download, the most interactive PowerShell development environment (IDE) for Windows administrators and developers.
Idera PowerShell Plus now has native Windows PowerShell support for local script debugging and code completion. Customize your UI, speed debugging, and work more efficiently.
What’s New in PowerShell Plus 5.0:
- Support for native Intellisense powered by the Windows PowerShell Abstract Syntax Tree APIs
- Support for native breakpoints for local PowerShell scripts
- Support for color highlighting and syntax checking for Desired State Configuration scripts
- Supports PowerShell 3.0 and higher and .Net 4.0 and higher**
Support for native Intellisense powered by the Windows PowerShell Abstract Syntax Tree APIs
Previous releases of PowerShell used the Windows PowerShell parser for evaluation of language tokens from the PowerShell 2.0 .Net Framework APIs. Each individual PowerShell Snap-in and Module was loaded and then enumerated using this parser to find the commands and functions and their associated elements (i.e. parameters) unique to the user’s machine to construct a cache. This cache was then used to power the Intellisense in PowerShell Plus but contributed to slow load time and inaccuracies when the cache was stale.
AST or Abstract Syntax Tree is introduced in Windows PowerShell 3.0. With ASTs you can easily find language elements as was once done with the PowerShell 2.0 parser, but also understand script structure and analyze it with parent-child relationships. This brings the ability to dynamically evaluate Intellisense requests without having to pre-cache that information, and therefore provide for faster load time after installing the product and running it the first time.
First-time evaluation is still needed to populate the PowerShell Reference help topic headings only. A new option setting in Startup is available to turn on/off the evaluation once the help topics are populated. This option is turned off after the product runs once. This option can be used to refresh the cache if a user installs a new module or you can still use the “press SHIFT” on startup to reload the cache for the sole purpose of refreshing the PowerShell Reference section of PowerShell Plus Help.
Support for native breakpoints for local PowerShell scripts
A breakpoint is a designated spot in a script where you would like an operation to pause so that you can examine the current state of the variables and the environment in which your script is running. Once your script is paused by a breakpoint, you can run commands in the Console Pane to examine the state of your script. You can output variables or run other commands. You can even modify the value of any variables that are visible to the context of the currently running script. After you have examined what you want to see, you can resume operation of the script.
In previous releases of PowerShell Plus, breakpoints were supported by setting an arbitrary marker in the UI and then using PowerShell Tracing, an available language feature in the PowerShell APIs, to track the breakpoint. Breakpoints using this methodology were limited only to lines and was prone to breaking under certain language conditions in PowerShell 3.0 (i.e. ForEach loops) because of bugs introduced by Microsoft in the Tracing function.
Using the PSBreakpoint language construct introduced in PowerShell 3.0, you can set three types of breakpoints in the Windows PowerShell debugging environment:
- Line breakpoint – the script pauses when the designated line is reached during the operation of the script
- Variable breakpoint – the script pauses whenever the designated variable’s value changes.
- Command breakpoint – the script pauses whenever the designated command is about to be run during the operation of the script. It can include parameters to further filter the breakpoint to only the operation you want. The command can also be a function you created.
PSBreakpoints are supported in both the PowerShell Plus Editor and Console and you can set breakpoints by either using the Editor convention of toggling breakpoints (i.e. Execution tab options or clicking in the left margin of the Editor) or the supported Windows PowerShell PSBreakpoint commands (i.e. set-psbreakpoint, remove-psbreakpoint)
Important Limitations in this Release
The following limitations apply to the use of PSBreakpoints in PowerShell Plus 5.0:
- Only Local scripts can be debugged using PSBreakpoints
- Debugging Remote Scripts and Workflow scripts are not supported
- The Breakpoint tool window only shows Line breakpoints – to see all breakpoints use the Console and the get-psbreakpoint PowerShell command
Support for color highlighting and syntax checking for Desired State Configuration scripts
Desired State Configuration (DSC) is a new management platform in Windows PowerShell that enables deploying and managing configuration data for software services and managing the environment in which these services run.
DSC provides a set of Windows PowerShell language extensions, new Windows PowerShell cmdlets, and resources that you can use to declaratively specify how you want your software environment to be configured. It also provides a means to maintain and manage existing configurations.
DSC scripts have a particular language format that was not previously supported by PowerShell Plus syntax checking and color highlighting. With this release, DSC scripts are properly syntax checked and color highlighted by the Editor enabling users to better identify mistakes when writing DSC scripts.
**PowerShell 3.0 and higher and .Net 4.0 and higher supported
Since we are using Windows PowerShell 3.0 and higher language features which have a dependency on PowerShell 3.0 and .Net 4.0 or higher, PowerShell Plus no longer supports Windows PowerShell 2.0.
If you would like to ask question or chat with others on PowerShell Plus, please visit our Forum.