Update: From September 4th, 2020, Visual Studio Codespaces is consolidated to GitHub Codespaces. The current Visual Studio Codespaces users will be notified to migrate their instances to GitHub Codespaces. From November 20th, 2020, no new Visual Studio Codespaces instance will be created and, from February 17th, 2021, Visual Studio Codespaces is retiring, and all instances haven't migrated to GitHub Codespaces will be deleted. For more details, please visit the official announcement blog post.
Since April 2020 Visual Studio Codespaces has been generally available. In addition to that, GitHub Codespaces has been provided as a private preview. Both are very similar to each other in terms of their usage. There are differences between both, though, discussed from this post. Throughout this post, I'm going to focus on the .NET Core application development.
Visual Studio Codespaces (VS CS) is an online IDE service running on a VM somewhere in Azure. Like Azure DevOps build agents, this VM is provisioned when a VS CS begins and destroyed after the VS CS is closed. With no other configuration, it is provisioned with default values. However, it's not enough for .NET Core application development. Therefore, we might have to add some configurations.
What if, there is a pre-configured .NET Core development environment ready? It can be sorted out in two different ways. One is configuring the dev environment for each project or repository, and the other is personalising the dev environment. The former approach would be better to secure a common ground for the entire project, while each individual in the team can personalise their own environment using the latter approach. This post focuses on the former one.
As a Docker container takes care of the dev environment, we should define the
Dockerfile. As there's already a pre-configured one, we simply use it. But let's build our opinionated one! There are roughly two parts – Docker container and extensions.
The sample environment can be found at this repository.
First of all, we need to create the
.devcontainer directory within the repository. This directory contains
Dockerfile, a bash script that the Docker container executes, and
devcontainer.json that defines extensions.
As there's an official Docker image for .NET Core SDK, we just use it as a base image. Here's the
3.1-bionic tag is for Ubuntu 18.04 LTS (line #1). If you want to use a different Linux distro, choose a different tag.
Now, let's move on for
setup.sh, we're going to install several applications:
- Update the existing packages through the
apt-getcommand. If there's a new package, the script will install the new ones. (line #1-9).
nvmfor ASP.NET Core application development, which uses
- The Docker image as on today includes PowerShell 7.0.2. If you want to install the latest version of PowerShell, run this part (line #15).
- If you want to use zsh instead of bash, oh my zsh enhances developer experiences (line #18-22).
We now have both
setup.sh for the container setting. It's time to install extensions for VS CS to use for .NET Core application development.
devcontainer.json is the entry point when a new VS CS instance is firing up. The
Dockerfile we defined above is linked to this
devcontainer.json so that the development environment is provisioned. Through this
devcontainer.json file, we can install all the necessary extensions to use. I'm going to install the following extensions for .NET Core app development.
- Azure Tools
- Bracket Pair Colorizer 2
- C# Extensions
- C# Sort Usings
- C# XML Documentation Comments
- Docs Authoring Pack
- Git Graph
- Git History
- GitHub Pull Requests and Issues
- Live Share
- Markdown All in One
Define those extensions in the
We've just defined all the extensions in the
devcontainer.json file. What else does this file do? It configures overall environments for VS CS to use. It's OK to leave as default, but if you really want to configure, please refer to this official document. Here in this post, I'll pick up a few points.
dockerFile: Set the value as
Dockerfilethat we defined above.
forwardPorts: When VS CS takes some ports, they need to be forwarded so that we can debug that on our web browser. For example, ASP.NET Core application needs both
5001ports, and Azure Functions takes
7071. Put these ports into an array and assign it to this attribute.
settings: It's to configure the VS CS editor settings.
All the environment setup is done!
.devcontainer directory back to the repository and run GitHub Codespaces. If you've already joined in the GitHub Codespaces Early Access Program, you'll be able to see the menu like below:
Click the menu, and you'll be able to access to all files within GitHub Codespaces.
In addition to that, we have both a PowerShell console and zsh console. Run the following command to create a sample .NET Core console app to start writing the code!
Program.cs should be looking like this!
After the login, unless you have a billing plan, you should create it. VS CS takes the consumption-based model, which means that you only have to pay for what you have used. If you don't need it any longer, delete it to avoid the further charge.
You will be asked to create a new instance if you don't have one yet.
Enter the requested information and create a new VS CS instance. The screenshot below links the GitHub repository, which is dedicated to the repository. If you don't link any of GitHub repository, it can be used for any repository.
So far, we've walked through how to set up the dev environment in VS CS for .NET Core application development. As this is the starting point of the team project efforts, it will significantly reduce the "It works on my machine" issue.