PowerShell Tools for Visual Studio Beta v0.5

If you haven’t seen the news, PowerShell Tools for Visual Studio is now available on the Visual Studio Gallery! The first beta brings with it many enhancements from alphas past and supports VS2013 RC. Here’s a quick overview of  the current state of the extension.


The current requirements for PoshTools are PowereShell v3 and Visual Studio 2012 or 2013RC. Several people have asked for VS2010 support and I’m researching the necessary changes. Also, there is a lot of interest in supporting VS2013 Isolated Shell. If the extension could be released in this manner it would make it completely free; just like the Python Tools for Visual Studio.

Editor Extensions

The extension adds language support to the Visual Studio editor. Some of the most important features are syntax highlighting, IntelliSense and code folding. IntelliSense with help you complete cmdlets and functions, variables and parameters. Code folding can collapse script blocks and comment blocks. Overall, syntax highlighting should be very similar to the ISE but there are known issues.


In addition to the basic functionality described above, the extension also adds support for the function navigation drop down bars on the top of editors. Using the v3 AST PowerShell API, I was able to discover the functions defined within the current file and present the navigation bars seen at the top of the editor window.

Function Navigation Drop Down

A big next step for the editor is snippet support but extensions do not support this; making it a bit tricky to implement. If you have a particular function you’d like you see in the editor, head over to GitHub.

Debugger Extensions

On top of the big changes to the editor there have also been some big changes to the debugger. The goal was the surpass the ISE in terms of debugging functionality. To accomplish this, I added support for the locals, break point and call stack windows.

The locals window shows all the variables in the current scope and enables the user to expand complex objects to dig down into the object. Just like when debugging other .NET languages, type information is provided. Next on the plate for the locals window is the ability to modify values at runtime. In addition to locals window support, I’m also looking at adding Watch window support.

Locals Window

Another key window when debugging is the break point window. It displays all current pending breakpoints that are set within all the open projects. Like any other break point, the file name and line number are provided. There is no support for conditional break points but would be a good feature to add in the future.

Breakpoints Window

Another important debugging window that is supported by PoshTools is the Call Stack window. Using the Get-PSCallStack cmdlet, the extension can display the current call stack when stepping or breaking in the debugger. There is currently no support for moving call stack frames and interrogating session state.

Call Stack Window

Finally, like with PowerGUI VSX, there is a project system dedicated to PowerShell. It’s been discussed to add different types of project systems for modules or generic collections of scripts but this isn’t currently the case. The extension exposes a project system that recognizes PSM1, PSD1 and PS1 files. In the current beta there is no support for automatic signing or manifest creation. There are dialogs created for this purpose but the MSBuild tasks and targets aren’t yet hooked into the project system.


Project System

I’d love to hear feedback about the current status of the extension. If you are trying it out please leave a review on the Gallery or enter any issues on GitHub.




You can leave a response, or trackback from your own site.

39 Responses to “PowerShell Tools for Visual Studio Beta v0.5”

  1. […] PowerShell Tools for Visual Studio Beta v0.5 (Adam Driscoll) […]

  2. Luís says:

    What about running powershell commands from vs?

    • adamdriscoll says:

      There isn’t a command window yet. I want to implement a custom tool window just like PoshConsole but have yet to implement. You can execute commands from any PS1 file.

    • Isn’t this what something like StudioShell (http://studioshell.codeplex.com/) brings to the table, in addition to allow you to script functionality directly against the Visual Studio IDE?

      • adamdriscoll says:

        Hey Gary,

        StudioShell’s intent is to extend and manage Visual Studio with PowerShell. This extension is intended to provide language support inside Visual Studio; not really extend the IDE. The two extensions certainly compliment each other.


        • Hello Adam,

          My question was actually in response to the comment regarding creating a Powershell Command Window. I was referring to the fact that things like StudioShell and Nuget Package Manager, already allow this functionality, so why another command window.



  3. Dennis says:

    Why was Microsoft Visual Studio Express 2012 excluded as a supported product?
    As a Powershell scripter, I do not have a need to shell out the money for a Pro version of Visual Studio.

    • adamdriscoll says:

      Express doesn’t support extensions. I realize that the price point doesn’t work for many people that are primarily PowerShell scripters. That’s why I’m looking to support VS2013 Isolated Shell. It’ll be completely free.

  4. […] PowerShell Tools for Visual Studio Beta v0.5 – Adam Driscoll highlights the beta release of the PowerShell tools for Visual Studio, bringing enhanced PowerShell support to Visual Studio 2013 RC. In the post Adam gives a run down of some of the useful features these tools add. […]

  5. Oisin says:

    There’s no need to add another powershell console when the nuget package manager console is able to execute powershell cmdlets, no?

    • adamdriscoll says:

      The only reason I would want to add another one would be to be able to execute commands in the same runspace as the rest of PoshTools. I would love to not have to re-implement it again…

  6. Craig says:

    Nice work Adam! I was using PowerGUI and the extensions from CodePlex prior to this because almost all of my scripts live in TFS.

    Installed the latest version of this right from the Visual Studio gallery and it worked on the first try.

  7. Craig says:

    You bet! The PowerShell track is usually closed to non-PowerShell MVPs, but I’ll try to sneak in again. Going to try to demo DSC for deploying and managing FIM.

  8. Henrik Nordtorp says:

    Finally a PowerShell extension that works! – I can now search and go to line and see functions in file :-) Thanks a lot Adam – nice Work.

    I’m a lot in PowerShell for SharePoint – is it possible to load the SharePoint CmdLet and have IntelliSense working for that part as well?

    • adamdriscoll says:

      Hey Henrik,

      Glad you dig it! As far as I understand, the SharePoint PowerShell snap-in is x64 only. Since Visual Studio is a x86 process, there is no way to loading the module directly. If I’m mistaken, you can certainly load any module into Visual Studio and get IntelliSense.


  9. Peter says:

    I have a very simple (and may be stupid ) question. Where is the output? I’ll get not output in the output window after running a simple script with F5.

    Otherwise great work and I am really looking forward to the custom Visual Studio shell.


  10. Peter says:

    Ok, “problem” solved -I had to change the execution policy inside package manager console.


    • adamdriscoll says:

      Hey Peter, glad you have it worked out. I think that I need to warn some how that the execution policy is restricted. The ISE shows a similar error when the policy is too strict but it’s not quite are obvious in PoshTools.

  11. nice work!

    stupid q: how do you pass command-line parameters to a script for debugging? in PowerGUI stand-alone it’s quite obvious…not so much with the VS plugin..

    • adamdriscoll says:

      Thanks! Not a stupid question at all. It actually isn’t support at the moment. If you want to submit a feature request to GitHub, that would be the best way to get it queued up!

  12. Rad says:


    Great work. Will this be an enhanced PS host then PowerGUI VSIX?

    You will remember (ScaffR open source project) when I showed you how to use PowerGUI VSIX PS script debugging to debug Nuget packages installations regardless of how many recursive calls there are.
    I explained below how I used PowerGUI execution enviroment with Nuget module and profile (by importing them)
    If you remember some things didn’t work and I asked you if it is possible to fix it.
    Like inability to step into new dependent script code (I was able to do that by intercepting Nuget package installation), inability to see yellow current line marker when stepping through a child scripts etc)

    I would like to know if the scripts executed by PowerShell Tools engine can use Nuget powershell console to output results and to interact with PowerShell Tools execution engine/context and variables that are currently in scope. I believe that one can output something to Nuget console but whenever you want to affect a variable it will be interpreted in the context of Nuget console PS host.

    Here is what I still want to do but with enhanced debugging (to step from PS script’s parent to child to child etc. like in the case of a Nuget package installation we need to recursively install kids’ packages and when that is done we can install parent (most dependent package).

    I did some complex debugging with PowerGUI VSX where I used PS script files and its Powershell command window and I imported Nuget modules which gave me ability to interact with IDE.
    My goal was to debug Nuget package installation when I have multiple levels of dependencies
    and I was able to figure out how to intercept a new package installation so I could step in a new Nuget install.ps1 script and see what is going on by inspecting variables.
    Some things didn’t work and I asked Adam if it is possible to fix it.

    I did it this way (not easy to understand unless you dig dipper into Nuget package installation process). I am interacting with VS IDE (DTE object):
    I used the first 2 lines in a NugetImport.ps1 file to bring everything that Nuget PS console needed so I can have the equivalent functionality using PoShTools enviroment
    and line 3. to set the current location
    Import-Module ‘C:\Users\rad\AppData\Local\Microsoft\VisualStudio\11.0Exp\Extensions\Outercurve Foundation\NuGet Package Manager\\Modules\NuGet\NuGet.psd1’
    & “C:\Users\rad\Documents\WindowsPowerShell\NuGet_profile.ps1”
    Set-Location (Split-Path $envdte.Solution.FullName -Parent)


    I can debug my script (let’s say Script.ps1) and I can happily step through Nuget installation process having 10s of recursive calls to sub nuget packages.
    (Some packages needed to be maassaged since they were made for Nuget console PS host))

    Notice that I have to override $dte variable to be $EnvDte variable from PowerGUI host so that it can be used throughout various nuget package Powershell install scripts

    $dte.Solution.SolutionBuild.StartupProjects = “MvcApplication1\MvcApplication1.csproj”

    if(-not(Get-Module -name “Nuget”))
    $ScriptPath = $MyInvocation.MyCommand.Path
    $ScriptDir = Split-Path -parent $ScriptPath
    . $(resolve-path “$ScriptDir\NugetImport.ps1”)

    $cm = Get-VSComponentModel
    #$InstallingHandler = [NuGet.VisualStudio.VsPackageEventHandler]{param([NuGet.VisualStudio.IVsPackageMetadata] $metadata) Write-Host “>>>Installing Package: $($metadata.Id).$($metadata.Version.ToString()) …” }
    #$InstalledHandler = [NuGet.VisualStudio.VsPackageEventHandler]{param([NuGet.VisualStudio.IVsPackageMetadata] $metadata) Write-Host “<<>>Installing Package: $($metadata.Id).$($metadata.Version.ToString()) …”
    #Write-log “>>>Installing Package: $($metadata.Id).$($metadata.Version.ToString()) …” -verbose

    function HandleInstalledEvent([NuGet.VisualStudio.IVsPackageMetadata] $metadata)
    Write-Host “<<>>ReferenceAdded for Package: $($metadata.Id).$($metadata.Version.ToString()) …”
    #Write-log “>>>ReferenceAdded for Package: $($metadata.Id).$($metadata.Version.ToString()) …” -verbose


    • adamdriscoll says:

      Hey Rad,

      Sorry for the delay in my response. Overall, the PowerShell Tools for Visual Studio should work much better than PowerGUI VSX in terms of debugging. I would suggest giving it a shot and seeing if it works better for you. This extension is completely different than PowerGUI VSX so I’d suggest uninstalling PowerGUI VSX before installing this extension.

      Please let me know how well it works for you and if there is any feedback I’d love for you to submit any issues to GitHub.


  13. Adam, thanks for the great tool!

    Is there any chance of incorporating refactoring into the tool? Functions like Rename and Extract Method (function) would be really useful when working on large scripts.

    Manual refactoring can be quite error-prone in PowerShell


    • adamdriscoll says:

      Hey Morgan,

      Thanks! I have had discussions with quite a few people that are interested in tooling like this. It would be really great but to create something really robust would be quite a bit of work. There is a lot that goes on in refactoring when you think about scoping, multiple files, and modules. That said, it would be good to start small and look at developing some good, single-file refactoring features.

      My suggestion would be to head over to GitHub and enter issues for the features that you are looking for. Complexity and community interest will drive what will eventually be implemented.

      Thanks for the feedback!


  14. Chris says:

    How do you wire up tests? I have working psate tests, but I’m not sure how to get VS to acknowledge them and run them in the IDE.

  15. Adam:
    Nice extension! What is supposed to happen when doing a build in Visual Studio? I see the files are by default set to BuildAction=Compile and Publish=True but, as far as I can tell, there is no output copy (and no build tab on the properties panel to specify an output path).

  16. Jai says:

    Does this support intellisensing var/functions in different ps1 files? I use dot sourcing to segment my projects generally. It only seems to Intellisense within the single ps1 file itself(?).

  17. Hello Adam,

    So yesterday I installed your extension’s update on a VM machine that we are using with Visual Studio 2015 RC. Sometime later that day I noticed that my TFS right mouse click in Solution Explorer, and in Source Control Explorer, no longer had the commands for Get Latest, Get Version… Check in…

    Some of the TFS commands were, but the really important ones I used everyday… they were missing. I didn’t think much about it or put the two events together, until today, when I was working with Visual Studio 2015 RC on my personal Dev machine, doing my normal daily work, checking in and checking out, when I noticed there were notifications about updates, and lo and behold, there was that update to the Powershell Extension that I had installed yesterday on the VM machine. So I clicked Update…

    Now my personal machine has exactly the same problem, the context menus for TFS commands for Get Latest, Check in… Get Version… etc are now missing from my Dev machine as well.

    I think your installer may have a nasty bug.

    Still haven’t been able to figure out how to restore them, I have to go into VS 2013 to access the operations from within it’s Source Control Explorer.

  18. Jalapeno Bob says:

    …. and here I am, stuck in the worlds of VS2005 and VS2010. We are a .org and keeping up with Visual Studio is something Other People do, similar to “Keeping up with the Kardashians” :)

Leave a Reply

In an effort to prevent automatic filling, you should perform a task displayed below.

one × 7 =