Why I use Visual Studio Code to write PowerShell

A Little History on PowerShell Editors

Since 2009, PowerShell users have been rewarded with an improvement over Notepad, for authoring PowerShell scripts and modules. That tool is called the PowerShell Integrated Scripting Editor (ISE), which was originally included out-of-box with Windows 7 and PowerShell version 2.0. Over the years, PowerShell developers have used tools like Quest PowerGUI and Visual Studio with the PowerShell Tools Extension to write, test, and debug their PowerShell code. In fact, not all that long ago, I wrote about moving from PowerGUI over to Visual Studio for your PowerShell development work. Since then, the momentum in the software field has gotten more and more agile, requiring developers to invest more and more time learning, and less time focusing on their business logic.

So Where Are We Now?

Over the past months, we’ve seen a rapid rise in a new, cross-platform editor called Visual Studio Code. Cross-platform software development is the real deal these days. No longer are we restricted to platform-specific software development tools; you choose the platform, you choose the development tools, and you start writing code.

Visual Studio Code, frequently abbreviated as VSCode, is an open source editor that’s built on the Electron user interface API from GitHub. One of the great things about VSCode is that it’s extensible, just like the full Visual Studio product is also extensible. You might be wondering: why should I use VSCode instead of Visual Studio? Well, to be honest, there are tons of things that I prefer about VSCode over Visual Studio, and I’ll outline these below.

Why You Should Use VSCode for PowerShell

Code Editing

The most important part of your software project is your code. Thankfully, VSCode gives you full control over your code with functions such as text encoding, customized indentation (2 spaces, please!), global search / replace functionality, revision control integration, and much more. One of the huge limitations of PowerShell ISE is that you can’t customize your indentation. I personally like to set my indentation to two spaces, instead of a 4-spaced tab, and VSCode gives me the ability to control that for my entire user account, or for specific workspaces (projects).

When writing code in any language, one of the most useful capabilities I enjoy using is Intellisense, or predictive typing. Intellisense, sometimes called auto-completion or tab-completion, reduces the amount of typing you have to do as a developer, reduces the memorization of API calls, parameter names, parameter types, and also reduces the need to context switch over to your web browser to look up API documentation. Documentation is super helpful as a developer, but if your development tooling can integrate documentation with code, you can be dramatically more efficient in authoring applications. Thankfully, the PowerShell Intellisense is pretty strong, albeit not perfect, in VSCode. Performance could be better, and there are bugs in the Intellisense, but all things considered, I’d much rather leverage the massive benefits of VSCode vs. being stuck in the old 2009 days of PowerShell ISE.

PowerShell Intellisense in Visual Studio Code

PowerShell Intellisense in Visual Studio Code


One of the most important benefits of Visual Studio Code is its performance. The full version of Visual Studio is incredibly powerful, reliable, and extensible, but that often came with a huge performance hit. This rang especially true if you had lots of extensions installed, or tried to load a very large project with lots of files. Of course, an adequately powerful developer workstation had no problem running Visual Studio, and many people use it today quite happily.

On the other hand, VSCode opens much more quickly, is much “snappier” when clicking on various UI elements and overall just feels very fast. Switching between major editor functions, such as the project explorer, search, revision control, debugging, and extensions, is very fast, and accessing components like the Command Palette (see below) is incredibly responsive, especially when hitting your favorite keyboard shortcut to invoke it. Overall, Visual Studio Code gets an “A” from me on performance.


In any software development environment, you’ll need the ability to extend and adapt it to your needs. It doesn’t really matter what language you’re authoring software in, you’ll still need build tools, debugging, rich text editing tools, revision control tools, and more. Visual Studio Code comes with built-in support for Git, but you can also download extensions that enable you to interact with Mercurial, if that’s your thing. There’s extensions that enable syntax highlighting, debugging, Intellisense, code snippets, custom file icons, and much more, for pretty much any language you can think of. There’s first-class support for Python, Ruby, C#, Java, PowerShell, and much more!

Visual Studio Code - PowerShell Extension

Visual Studio Code – PowerShell Extension

Project Management

One of the cool things about VSCode is how it manages projects. In short, you can open any folder on your filesystem as a project. This means you can scope your editor to a specific application component that you’re focused on, or you can get a larger perspective of your entire project by opening a folder a few levels up in your folder hierarchy. Of course, you can open individual files too, but being able to open an entire folder as a project is a huge benefit that VSCode has over the PowerShell ISE. In the PowerShell ISE, it was easy to get lost in your project if you weren’t paying close attention to which file you were editing. With VSCode, that problem disappears for the most part!


Visual Studio Code - High Contrast Theme

Visual Studio Code – High Contrast Theme

While it may sound trivial, the ability to create and apply custom themes to Visual Studio Code is really awesome. It’s nice to have a change of pace throughout your day writing code, and switching your theme takes a matter of a few seconds. You can also search for new themes on the Visual Studio Marketplace, and install them, all directly from VSCode. The theme that you use in your development environment depends a lot on your physical environment and your mood. Sometimes I like a deep, colorful theme, sometimes I like muted, soft colors, and sometimes I like a nice high-contrast theme. The great thing about VSCode is that I can get all of the above with a few simple key presses.

Want to install a theme, or change your theme? Simply launch the Command Palette and search for “theme” or “extension.” In the Visual Studio Marketplace, themes are considered extensions.

PowerShell ISE offers limited support for themes, and I actually wrote a PowerShell module to import themes in ISE.  However, previewing and switching themes is nowhere near as easy as VSCode!

Command Palette

I’ll be honest, the Command Palette is a game-changer in software user interfaces. After having the Command Palette available in Visual Studio Code, I started wishing that every piece of software out there offered a similar user interface. The Command Palette enables you to search for the function that you’re looking for, rather than resorting to manually using your mouse to look through all of the menus at the top of the screen. Want to do a “git push?” All you need to do is search for “push” and it will come up. Want to perform some PowerShell-specific operation? Pull up the Command Palette, search for PowerShell, and you’ll see all of your commands neatly filtered in the Command Palette.

Another massive benefit of the Command Palette is that you can not only search for development environment commands, but you can naturally learn keyboard shortcuts along the way. Don’t know what the keyboard shortcut is for a particular editor command? That doesn’t matter, because the Command Palette will show you the keyboard shortcut when you search for a command. That way, the next time you need to call that same command again, all you have to do is use the keyboard shortcut, and you’ll be on your way to deep productivity!

Visual Studio Code - Searching the Command Palette

Visual Studio Code – Searching the Command Palette

While the Command Palette can easily be invoked with CMD + SHIFT + P, or just hitting the F1 key, another really cool feature of the Command Palette is the keyboard shortcut to switch between files in your workspace (project). All you do is hit CMD + P, type a small, unique part of the file you want to edit, and hit ENTER. BOOM! Just like that, you’ve opened up the editor to your desired file, and you didn’t even have to touch the mouse!

Conversely, the PowerShell ISE lacks any ability to switch to specific files using your keyboard, much less using search. Sure, you can use CTRL + TAB and CTRL + SHIFT + TAB to go forward and back between open tabs, but if you have a large number of files open, this can be a huge pain to navigate.

Rapidly Switching Files in VSCode

Rapidly Switching Files in VSCode

User Interface

The user interface in Visual Studio Code scales very well, which is especially useful on high-DPI displays. When you scale up the user interface, text and icons scale proportionally together. My guess is that most of this is thanks to the Electron API, but then again, I’m not familiar with the code base of VSCode that much. The UI is organized well, full screen mode works awesome for when you really need to get focused on writing your code, and you can even collapse the sidebar to maximize your screen real estate for your code editor area. I really love how “open” the VSCode editor experience feels, and it gives you, the user, a lot of control over how much or how little you want to see on-screen. This level of control helps VSCode have a “lightweight” feel to it.

On the flip side, the PowerShell ISE does not scale well on high-DPI displays. While ISE is built on the Windows Presentation Foundation (WPF) UI framework, which can scale well, it seems that the PowerShell ISE’s main menu and toolbars have been artificially restricted to a specific pixel size. Of course, I can’t validate that myself, but I’m just reporting my observations here. On a positive note, your code in PowerShell ISE does scale very well, with nice, crisp text; that’s one thing I’ve always loved about ISE.

Searching Your PowerShell Code

With the PowerShell ISE, it was easy to get lost in your code, and it could be very challenging to find references to functions, aliases, and other elements. In VSCode, you can search your entire folder project at once, using the powerful, built-in search feature, which is easily accessible using a keyboard shortcut! You can perform search and replace operations using regular expressions across your entire project, all at once. This feature isn’t one that I use particularly frequently, but knowing that it’s there is super useful if you’re in a bind, and need to find something across a huge number of files.

On the downside, the PowerShell extension for VSCode doesn’t support certain features like “Go to Definition” and “Find All References.” This is partially due to the dynamic nature of PowerShell and the fact that there isn’t a lot of analysis that can be done on your code before run-time, like with C# applications. However, the team that’s working on VSCode’s PowerShell extension is aware of these limitations, and hopefully we’ll see some improvement on it going forward.

Searching a PowerShell Project in Visual Studio Code

Searching a PowerShell Project in Visual Studio Code


While VSCode may not be everyone’s cup of tea, I certainly love the fact that I can write PowerShell code effectively on a non-Windows system. I haven’t given it a solid go on Linux yet, but I’m fairly confident that it will work almost just as well. Between the vast array of functionality, themes, extensions, and performance that it offers, I really feel like I’m in control of my software development experience when I’m using VSCode. If you aren’t using VSCode for PowerShell today, I’d encourage you to toss away your old editor, shift over to VSCode as your “daily driver,” and really invest yourself in learning about it and appreciating what it can offer you in terms of productivity.

  • Naïve question. bit can you step through a script to debug it in VSCode like in ISE?

    • Mike Buckley.

      VSCode has a full suite of debugging tools, and the additional features, such as monitoring variables etc. is far better than ISE or any of the ‘paid’ apps IMHO

      • I had VSCode but hadn’t been using it. Installed again today along with running “ext install PowerShell” and will give it a go!

        • Hey Shawn! it’s been a few months since this comment. Have you switched over to VSCode fully yet? I use it every day!

      • Agreed, Mike! I just wish the debugger was a bit more reliable. The PowerShell engine, or maybe the extension itself, crashes on me a lot, which causes disruption during development work. I love VSCode for editing code though, so what I normally do is run / test my code in a separate terminal session using iTerm on Mac.

    • Latest release of VS Code and the PowerShell Extension offer more robust debugging. They integrated similar debugging to what you can do in ISE with use of the Set-PSBreakPoint. A future relase of the extension is supposed to include added features where you can more easily debug a full module (last I read anyway).

      • Yeah, the PowerShell extension for VSCode seems to still crash pretty often for me though. I love VSCode for editing, but for debugging, I’d like to see a more reliable experience. I’m sure it’ll get there in time. What I do in the meantime is run my code in a separate terminal session, using iTerm on Mac.

        Trevor Sullivan

        • I have found with SMO and debugging scripts I can cause it to crash pretty easily. However for the most part (average) it has smoothed out a good bit in the last few releases. Although, I only ever use the integrated debug now…seems to hold up better when debugging modules.

          • Good to know! I’m still seeing weird characters get printed in the Integrated Terminal. Do you ever get that, and have to restart the PowerShell session?

            Now that David Wilson has left Microsoft, and gone to GitHub, I wonder if Atom Editor is going to get better PowerShell support. 🙂

          • Yeah, some of the text being printed wacky I’ve read is supposed to get fixed…but with David leaving I have no clue who at MS is going to be managing that project now.

  • jkavanagh58

    I still prefer the ISE

  • Mike Buckley.

    I am torn on this one. While I see the advantages to VSCode, I still think it is far to immature to ‘bet my life’ on it. It still has many shortcomings, and until I see more features, it will be my second or third choice.

    I do however love ISESteroids, and find that it has been well worth the investment for a license.

    • Hi Mike,

      If you think of it more as a pure editing experience, rather than an execution environment, it works a lot better. The truth is that PowerShell ISE isn’t getting much love and attention from Microsoft, and Visual Studio Code provides editing features that ISE can’t even begin to compare to. Searching across projects, automatically formatting code, side-by-side windows, rich theme support with a marketplace, configuration of editor via settings files, etc. etc.

      I’d recommend using PowerShell Console Host via ConsoleZ or ConEmu to run your tests, and use Visual Studio Code to actually write your code. Of course, you might need to make some adjustments to how you currently structure your projects / code, but it’s well worth taking the time to do so.

      Trevor Sullivan

  • cantorisdecani

    A recent article I saw about VSCode showed after its being opened your having to set it to PowerShell mode and then open the Output pane and then set that to PowerShell too. Maybe a multi-language developer might like this but I’m a Windows admin dipping his feet in semi-developery areas. I don’t see anything to even slightly encourage me away from the amazing ISE Steroids!!

    • GS

      If you name you script with ps1 extension you don’t need to do anything additional to rundebug PowerShell. iSE steroids is not free so no reason to compare.

    • It is based on what version of Windows you work with. If you are on Windows 10 and latest version of VS Code it will default to PowerShell for the integrated terminal. If you utilize task they will also utilize the integrated terminal now instead of the output panel.

    • Robert Wegner

      Steroids has some nice features, but is an optical nightmare. The buttons are just colorful blobs and the features are cluttered all over the place. This would be less of a problem if you could customize the toolbars, but you cant. I tried to use steroids a few times now, but it’s like they never used an intuitive UI before.

    • William Davies

      Ctrl-J opens the tabs at the bottom (Problems, Output, Debug, Terminal)
      When’s the last time ISE offered half of what VS Code offers for Powershell developement

  • Pingback: Dew Drop - February 27, 2017 (#2430) - Morning Dew()

  • Matt McNabb

    The biggest win for me right off the bat was VSCode’s folder-based project explorer. This was something I always wanted in the ISE but was never delivered. That and Git integration.

    It took me a while to convert over completely, but mostly that was just because I’d developed my habits around the behavior of the ISE. I’m now getting used to debugging in VSCode and the options to run selections of code are excellent! There is so much that you get out of the box with this that costs a pretty penny in other IDEs.

  • Pingback: Change VSCode Integrated Terminal to PowerShell - Trevor Sullivan()

  • Pingback: Why I use Visual Studio Code to write PowerShell – Trevor Sullivan – Powershell()

  • Charlie Spencer

    Like cantorisdecani, I’m a Windows admin by trade. I’m learning PowerShell, but I find I’m spending almost as much time having to learn about development concepts in general and development tools, mechanics, web sites, and terminology.

    I’m trying Visual Studio Code as an alternative to PowerShell ISE. VSCode itself starts okay but as soon as I open an existing file or try to start a new one I get an error ‘The language service could not be started’. I also get a ‘PowerShell Initialization Error’ message in the bottom right corner of the VSCode window.

    Googling the error wasn’t any help. Any suggestions on where I might find a solution? PS 5, W10 64-bit Ent, VSC 1.14.2 64-bit

    Thanks, regardless.

    • Hey Charlie,

      I’d recommend setting up verbose logging on Visual Studio Code for the PowerShell Extension, and sending the logs over to the project, so they can help determine root cause. That is going to be your best bet to finding a resolution.

      Go here: https://github.com/PowerShell/vscode-powershell
      Go to Issues
      Create a new Issue
      Read through the template issue for directions on how to report logs

      Trevor Sullivan

      • Charlie Spencer

        Thanks. I’m new to web-based development models and am unfamiliar with many of the processes. (When did we start calling programming, ‘developing’?) Somehow I tripped over an already open issue so I added to that.

        Then I had the joy of creating a new issue after all, when I found VSCode doesn’t like a ‘Get-Help’ cmdlet if I add the ‘-ShowWindow’ parameter. At this point in my learning, I live in Get-Help and really prefer the window option over scrolling in the console.

        Between these issues, I think I’m better off sticking with ISE at the moment. Learning PS is enough without making the learning curve steeper with VSCode, learning how to interact with development sites, etc. I need to concentrate on debugging my own stuff without the distraction of debugging the work of others. I also think VSCode contains more capabilities than i can take advantage of at this stage. Maybe down the road several months I’ll take another look at it.

        Thanks for the response.

  • Agreed!! Great writeup for all languages + powershell!

  • Pingback: Some Tools of a PFE | automatizeblog()

  • Jim Coryat

    @disqus_tznWipUeuW:disqus this is a known issue. I get the same error and I have not found the silver bullet that fixes the problem. Some contributors have suggested to run VSCode as an Administrator which solves some problems. I have not had any success with that approach. I have been a software engineer for 30 years, so this is not new to me. I was hoping to get git integration into my IDE without losing any other features I have today. Overall the lack of integrated debugging makes it less desirable over using the Powershell ISE. However in with Powershell 5.0 intellisense seems to be broken as well with little in the way of possible solutions. Hopefully the Powershell and Visual Studio Code teams are working on the issues. On the positive side the development experience in VSCode is much nicer than that of Powershell ISE. I have been watching VSCode and watching the increased level of maturity, but at this time I think it still needs some more stabilizing. What I see right now is a large and growing Powershell community and definite gap in the availability of a good solid IDE.

    Nice write up Trevor!