Moving From Visual Studio to VS Code as a .NET Developer

Like most developers, I've always used Visual Studio for C# development. But between VS Code's rise to power and .NET Core's OS agnosticism, it feels like the time for a switch.

Visual Studio Sucks

I've been using Visual Studio for nearly a decade and think it is probably the most powerful IDE available. It has an enormous set of features and handles mountains of configurations and commands "behind the scenes," without forcing the developer to waste time dealing with these things.

However, this type of automation becomes very frustrating when things break down. For instance, when you realize that Visual Studio is using its own version of Angular stored somewhere in your system files, and that Microsoft decided to make this a hassle to change...

I'll admit that this type of automation is extremely useful for getting started with a new stack, but these days I'd rather sacrifice a bit of time dealing with configurations if it means I'm given more control. Also I don't really like being forced to develop on Windows.

This is the reason I'm switching. Not because I can set my VS Code to be Hatsune Miku themed. That's certainly not the reason why.

C# Extension

You're going to need Microsoft's C# Extension to handle everything C# related within VS Code, including attaching to processes and debugging. Also Intellisense. Can't live without that.

Solution Files?

Solutions are specific to Visual Studio and have no place in VS Code. Instead, VS Code uses Workspaces which can contain groups of projects similar to Solutions. In this case, they're called "multi-root" workspaces.

Within a VS Code project, you can define launch configurations and other tasks for each project within the .vscode/launch.json and .vscode/tasks.json files. The same configuration format can be used within the Workspace file to define the behavior for launching multiple projects at once.

Since the Workspace file can access launch configurations defined on the project level as well, things are very nice and modular to work with. What I usually do is define all of the individual launch configurations for each project within my Workspace, and then use compound launch configurations at the Workspace level to call many of the project launch configs simultaneously.

Workspace Structure

I've found it the most practical to keep each project in their own separate repository, and then create an independent repo for storing the Workspace files. An alternative is to keep your workspace files in the "most important" repository, and use relative referencing to the other projects, but I'm not a fan of this since it mandates the use of the "important" repository, even in cases where you don't necessarily need it.