Whenever I am a speaker at Microsoft events, many people seem to be confused by my MacBook Pro. The first thing they probably think is that I’m a mobile developer, and I have a virtual machine with Windows to use Visual Studio. At least the explicit questions like “what does a Microsoft guy do with an Apple device?” are over. Maybe the religious wars are giving way to pragmatism, or perhaps the news that we have .NET Core since 2016 and that we can develop ASP.NET applications from the Mac is starting to get more popular.
One of the great new features of .NET Core is the Command Line Interface (CLI), which allows us from the command line to create projects, compile them, run them, download libraries and also package code to be published on NuGet. However, Microsoft developers historically avoid two things like the plague: JavaScript and the command line. And above all, they continue to delude themselves that a preview of Visual Studio can replace the result in execution of an application. We are in 2020, the market has changed, the way of developing applications is completely different today, and don’t keep up with the times can be fatal.
The first cross-platform alternative to Visual Studio is Visual Studio Code. It is a code editor, not an IDE (Integrated Development Environment), but it has at least three characteristics that make it my favorite development tool:
- It is free and Open Source
- Cross-platform
- It is highly customizable thanks to the extensions that you can download from the marketplace.
It is not just any editor, is designed for development, therefore it has native support for the management of the source code (Git), a debug environment (configurable). It works on the concept of the folder. Those who use Visual Studio are familiar with the idea of solution, which is an artifact closely linked to the .NET world. With the use of other technological stacks, for example, NodeJS, the concept of solution does not exist, therefore Visual Studio Code prefers to work on single folders or workspaces (set of folders).
Technically, we are talking about a JavaScript application that runs inside Electron, an exciting project that allows you to “box” a JavaScript, HTML and CSS application in a cross-platform Desktop container. If you are interested in learning more, I gave a talk at various Italian conferences, some of which are still available on YouTube.
Obviously, all the project creation wizards are missing, still it provides one or more terminals integrated into the application (bash, Powershell, etc.) from which we can launch the commands we need. If you have a huge screen, you can also place the terminal windows side by side, in order to make it easier to start several commands at the same time.
The idea is, therefore, to start from your needs and configure the environment as you prefer. For example, suppose we are C# developers and want to configure Visual Studio Code for the realization of .NET Core applications, first, we will install the following plug-ins:
To see the plug-ins in action, let’s create a WebAPI project with the .NET Core CLI, and open the project in Visual Studio Code:
dotnet new webapi -o backendcode .
Visual Studio Code realizes that there is a .NET Core project because we have installed the official C# extension, and asks us if we want to configure the environment for debugging (the launch.json file) and task automation (task.json):
A .vscode folder is then created with the configuration files:
We just need to put a breakpoint in the code and run the debug:
But let’s go further, adding an Angular client to our project directly from the integrated terminal, launching the command to create a new Angular project:
Waiting for the wizard to finish, let’s install the plug-ins to support development in Angular. The quickest way is to install Angular Essentials, by John Papa, which is an Extension Pack, that install all the plug-ins that can be useful with Angular development.
Usually, I prefer to debug an Angular application directly in the browser, but we can configure Visual Studio Code to attach the Chrome debugger. We need to install the official Microsoft extension and add a Launch Chrome configuration in the Debug panel (launch.json):
At this point, we just need to change the port to the 4200 value and set the webroot on the frontend folder. Let’s put a breakpoint, launch the frontend from the terminal with the ng serve command and attach the browser debugger from the debug section:
We can also ask Visual Studio Code to launch the front-end for us, using the npm start script from a specific task in the tasks.json file:
{
"version": "2.0.0",
"tasks": [
…
{
"label": "start-frontend",
"type": "npm",
"script": "start",
"path": "frontend/",
"isBackground": true,
"problemMatcher": {
"owner": "typescript",
"source": "ts",
"pattern": "$tsc",
"background": {
"activeOnStart": true,
"beginsPattern": {
"regexp": "(.*?)"
},
"endsPattern": {
"regexp": "Compiled"
}
}
}
}
]
}
The problemMatcher section allows us to understand when a task has finished even if it is actually waiting, in our case, when the output contains “Compiled”. At that point, we can open the browser and attach the debugger using the previous configuration, to which we add the preLaunchTask with the name of the task just created:
{
"type": "chrome",
"request": "launch",
"preLaunchTask": "start-frontend",
"name": "Launch Chrome",
"url": "http://localhost:4200",
"webRoot": "${workspaceFolder}/frontend"
},
Once our application is complete, the time comes to deploy it. Do you use Azure? Nothing could be simpler: we install the Azure Tools plug-in, which adds a whole new section to our editor:
I can continue indefinitely, adding support for Docker and Kubernetes, for example, but I think I get the idea across to you. We end up with two other features without which my life as a developer, teacher, and speaker would not be the same. The first one is the possibility to create our snippets by simply clicking on the main menu, Preferences > Users Snippets section: you will be asked to choose the language for which you want to create snippets, in order to open the corresponding JSON configuration file for you:
For example, let’s create a C# snippet that adds the configuration of a DbContext EntityFramework that uses SqlServer as a database:
"DbContext Sql Server": {
"prefix": "demo-add-dbcontext-sqlserver",
"body": [
"var connection = @\"Server=$1;Database=$2;User=$3;Password=$4\";",
"",
"services.AddDbContext<$5>(",
"\topt => opt.UseSqlServer(connection));"
],
"description": "DbContext Sql Server"
}
Let’s give a name to the snippet, specify the prefix (in our case demo-add-dbcontext-sqlserver) with which we want to use it, write the body of the snippet in the form of a string, add a description that will be reported by the IntelliSense and the problem is solved The possibility of using numbered placeholders using the $ symbol is very useful: it allows us to add in the body the points we want to make customizable and the order of the tabs with which to move among the changes:
If you have seen me at any event doing live coding, now you know my secret!
Last but not least, we have the Live Share: the possibility of working with your colleague on the same source in remote Pair Programming, one of the reasons that led Facebook to choose Visual Studio Code as a development tool. By installing the extension and clicking on the live share icon in the status bar in the footer, you will be asked to authenticate with a Microsoft or GitHub account, that connect you to the platform, and the link to be sent to your colleague will be copied to the clipboard to start the sharing session:
I want to conclude by clarifying that this way of developing is not for everyone; it requires a good knowledge of the command line and of what happens behind the scenes. In a work environment, productivity is essential, so if Visual Studio makes you more productive, it is welcome, even if, in my opinion, it is not an excuse to ignore what happens behind the scenes!
Happy coding!
