You can install Visual Studio code on your device (Windows/Mac/Linux), but you can also use it from within your browser. In this blog post, I will show three ways to start your Visual Studio Code session.

What is Visual Studio Code?

“Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running, and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual Studio IDE.”

Source: https://code.visualstudio.com/docs/supporting/faq

How to use Visual Studio Code

Local installation

I think this is the most used option 😉 You can download the installer for your Operating System of choice here. After installation, you will be presented with a wizard to configure VSCode to your personal preference, and you can add your GitHub account, etc. I wrote a blog about using VSCode instead of ISE here, which contains these steps.

In a browser using Vscode.dev

This is a web-based version of Visual Studio Code, and it can be accessed using https://vscode.dev in any modern browser. On the first start, it looks like this:

You can turn on your Settings Sync to import the settings from the VSCode installation on your computer (Settings icon in the lower left corner followed by Turn on Settings Sync) and use your GitHub or Microsoft account.

After loading your preferences and extensions, you’re good to go to edit your scripts and files. But you can’t run/debug PowerShell scripts in vscode.dev:

Note: Vscode.dev is excellent for quick editing, updating, or viewing PowerShell scripts. For running/debugging, you should use your local installation or the Docker container option.

In a browser accessing VSCode from a Docker container

I use Docker on my laptop for testing things, and you can also use it to run a VSCode container. I used https://hub.docker.com/r/codercom/code-server on my system. (You can also run it on your NAS or Raspberry Pi. Check for processor support in that case (ARM64)) Check out the installation steps on that page to spin up that Docker container. If you follow the steps correctly, you will have the sudo password that you will need later on to install PowerShell in the container.

After starting, it will look like this in your browser:

It will ask me if the default ~/workspace path should be trusted, and after answering that question with “Yes, I trust the authors” and completing the wizard… It looks like this:

You can’t access your local drive because it’s running in a Docker container. (You could use the Volumes feature to link local folders inside the container, but I didn’t choose that option) I store all my scripts in GitHub and used the Clone Git Repository to get all my PowerShellisfun files in the Docker container. After connecting GitHub and cloning my repository, it looks like this:

Installing PowerShell within the Docker container is the next step. You can do this by following the steps for Ubuntu (Because the container is based on that) here. You can copy/paste the commands into the VSCode terminal, which you can access by using CTRL-Shift-P and typing terminal, and selecting the JavaScript Debug Terminal. You will be prompted to enter the password which you used in the Docker configuration.

Note: You could get a prompt from VSCode asking if you want to install PowerShell during the first setup steps. This was not very consistent for me, and the above procedure always works 🙂

To run or debug your scripts, you have to install the PowerShell extension first:

The setup is done now, and you can develop PowerShell scripts using this solution.

Note: This instance of VSCode is running inside a Linux container. Windows-based cmdlets/functions will work because of that. But that’s something that Linux or Mac users are already used to 😉

Conclusion

There are options for Visual Studio Code to not only run it on your local system, but there are limitations when developing PowerShell scripts. Which one is the best option for you depends on personal preference and/or use case, but there are options 😉