Powershell Analyzer Roadmap
This is our intended roadmap post 1.0, currently we are in Beta 4 of our initial 1.0 release, but are getting close.
With 1.0 we had lofty goals and we have met them, we have implemented a broad range of features, so very well polished, some just scratching the surface. Our goal was to create an IDE and editor that would excel in over 95% of the situations that people would be using PowerShell, and I believe we have succeeded. Beyond version 1.0 we want to do a lot of the things we are already doing, but do them even better.
Version 1.1 – “Code Completion”
In version 1.0 we supplied code completion for about 15 or so scenarios. In 1.0 we plan to have far more extensive code completion support, with a complete PowerShell language semantic parser. Currently code completion now just happens on certain triggers like “-“ for cmdlets, and "." or "":: for members, in 1.1 we will be able to trigger code completion at anytime in the expression, and will support Tab, as the PowerShell.exe console also does, and Ctrl-Space for all you VisualStudio.net users. We plan to also allow the users to select which rules they want to be using for their code completion, as well as exposing an interface that will enable people to either write dotnet plug-in DLLS or equivalent PowerShell script to generate custom code completion, along the lines of Mow’s PowerTab. Also, expect general GUI refinement and a throng of small features common to traditional IDEs.
Version 1.2 “Debug This”
The interactive nature of 1.0, as well as certain features, like hovering over a variable to see its content and rich output visualizers of PowerShell Analyzer 1.0, already give the users a lot of power to debug the PowerShell expressions and scripts they are sculpting. However, this is an area we can add a lot to, even though the underlying PowerShell engine is quite lacking in debugging functionality. In Version 1.2 we will add improved error reporting, and interaction with errors, with such ability to be able to press a hotkey and go to the line/word where the error originated. We will include some Tracing functionality and breakpoints, even breakpoints within a Script-Block inside the pipeline. We may include watches, and the option of conditional breakpoints (controlled by PowerShell script), and the ability to run command line commands while code is stopped by a break point.
Version 1.3 “True Host”
With version 1.0, we made a call about making our “console” accurate or not. We decided that foundational features like multiple run-spaces, code completion, and “suspend shell” were more important, that colored output or the ability for scripts to be able to move the cursor as for the majority of use-cases (95% +) these features were just novelties. However with version 1.3, we want to make the console experience to be as close to the real console as possible, supporting color, writing/reading from the buffer, moving the cursor, and dealing much better with requests for user input. The area we especially want to ensure works better than it currently does, is interaction with non-PowerShell and native calls.
Version 1.4 “Result and Provider Explorers”
With this build we want to revisit our result explorers and provider explorers, enhancing the standard ones like XML explorer and the hierarchical and grid result explorers. Primarily so that custom objects show their properties as columns and also automatically show ado.net datasets and datatables if they are the results of the PowerShell query. We have a lot of exciting ideas to improve this innovative features of PowerShell analyzer. Also we intend to make it into a plug-in engine, so that third parties can write plugins for a visual explorer of the types generated by their product, or types they are interested in. As for the provider explorer, there are a lot of things we want to do with it, including having visual cues, and menu-items for the standard provider operations (like copy, new , delete), as well as the ability to paste the current path into a script, integrating both your script and GUI experiences. Also we want to provide a plugin engine here also so that people can write plugin visualizers for specific PowerShell providers (i.e somebody could write a PowerShell SQL provider, and also a PowerShell analyzer provider explorer plugin to go with it.)
Version 1.5 “Charting to the extreme”
Powershell Analyzer has had charting in it for quite some time now. But it's not very customizable, despite the power of the underlying charting engine. We plan to expose this power and turn PowerShell analyzer charting into a tool that many will want to use everyday.
Above is our intended roadmap, and it may change over time depending on feedback from customers on what the most important requirements are, and also the many of the features of version 1.3 might sneak in beforehand, and I’m sure there will be some revision of them after 1.3 as well. Beyond this we also have plans for visualizers, exporers and wizards for WMI, active directory and specific products that are built on top of PowerShell (i.e. exchange 2007)
Others projects / products
Background Pipeline
We include some scripts in the open source Powershell Community Extensions (PSCX) project. We will be incorporating our background pipeline set of cmdlets in there, that allow you to write “multi-threaded” PowerShell.
PowerShell Analyzer Snapin
We will be producing a snapin that can be run from the windows PowerShell.exe console, that has PowerShell specific features (i.e out-PSAchart , out-PSAhtml), so that scripts you build that may use PowerShell analyzer specific features, aren’t restricted to be only run in Powershell Analyzer.
Integrated PowerShell Host and Editor component for developers
We are building a system by which products that base their foundation on cmdlets, but provide a GUI on top of them, can do so easier by going through our host, and thus allowing an integrated customizable domain specific PowerShell scripting environment in their own application. For example exchange 2007, builds all of its administrative functionality into cmdlets, and has a MMC Gui interface that effectively calls the underlying PowerShell cmdlets. The Gui can display the equivalent code of the GUI task, and they provide a console based “exchange management console” where admins can run exchange specific PowerShell expressions, commands and scripts. Well once this product is complete a company building a system in a similar way to exchange 2007, could use our hosting environment to simply their development and have a GUI based integrated editor and environment that users can run, develop, and edit custom scripts and expressions. In a way it is like the integrated VBA , however more customizable and integrated into the final product.
PowerSQL
We have built an early version of PowerShell integration into SQL Server 2005. We may or may not pursue turning this into a professional level product.
Various experimental products
We continue to push the envelope and mindsets of what a console is, and how people can effectively, quickly and powerfully interact with it and leverage the power of PowerShell. In time you may see some screenshot, videos and maybe some demos of techniques, and they may be rolled into Powershell Analyzer, or other products depending on what makes sense and our customer feedback.