New tricks for an old dog – what I learnt from VS Code

After nearly a decade of coding in Visual Studio, a recent change in employment has put me in front of VS Code. The experience has had its ups and downs, so I thought I’d post a few pointers for anyone else who ends up in my situation. Moving beyond practical matters, I’d also like to take a moment to reflect on what the experience of weaning myself off Visual Studio has taught me. Zooming out further still, I close this post by considering what VS Code says about the state of the .NET ecosystem and try to put it all in perspective. If you can stomach all that, read on…

Disclaimer – I’ve been using VS Code solidly for a month now, but am certainly not an expert. If I’ve got something wrong, shout at me in the comments!

Quickstart guide

For everyone coming to VS Code from Visual Studio: listen up! We’re going back to basics here, rookie. Try to forget everything you think you know about an IDE.

Out of the box, VS Code does very little. Think of it as a skeleton on which you can hang the flesh of your very own development environment. The “flesh” in this case is made up of extensions, which in my opinion are (unlike in Visual Studio) not optional .

For the typical C# developer, I’d highly recommend the following extensions:

1. C# for VS Code (powered by “Omnisharp”) – An obvious one, but worth pointing out. This is where you’ll find your old friends “debugging” and “Intellisense”. There are other extensions that have some feature overlap, but this seems to be a good bet for most C# devs.
2. .NET Core Test Explorer – Yes, you can run your tests with dotnet test , but why deprive yourself of a handy tree view for your tests? Not to mention the code lens, which displays test results above the tests and provides a shortcut for running/debugging them.
3. Gitlens – I only found out about this one recently, but it’s pretty snazzy. VS Code comes with some functionality for Git, but Gitlens supercharges it with improved comparisons, the “blame” code lens, and a change heatmap in the gutters.

OK, so you’ve got your extensions. Great stuff. The next step I’d suggest is to go and muck about with the “command palette”. It’s a bit like a command prompt for all the functionality available in VS Code (including from extensions). Press ctrl + shift + p to bring it up and start exploring what you find there. If you get stuck, just enter a question mark for contextual help. Once you get to grips with the command palette, you’ll quickly become a speed demon.

One final tip… for those of you that (like me) appreciate a well-tailored development environment, it is easy to add Fira Code and super simple to change the colour scheme .

What I’ve learnt

This is where it all starts to get a bit navel-gazey. If you’re just here for the tips, I won’t be offended if you quietly slink away now…

As someone who’s spent a reasonably long time working in C# and .NET, I wasn’t expecting to find VS Code to be as different as it is. Whether it was the name or the company backing it, I guess I was anticipating it to be more like Visual Studio. Superficially, I was surprised by how fast it is and how stripped back it is. The lack of hand-holding was a jarring shock, but the flexibility and speed seem like a fair trade-off.

On a deeper level though, I was surprised by how much VS Code challenged my preconceptions. With hindsight, a lot of my knowledge and experience in working with .NET and C# was inextricably intertwined with my knowledge of Visual Studio. So much of the process is nicely abstracted away behind the UI in Visual Studio that you really don’t have to think about what it’s doing to make your code run – you just press that nice green play button and off it goes.

VS Code and the Dotnet CLI have – in a very real way – reconnected me with the craft of software production, above and beyond simply writing code. By taking off the stabilisers (“training wheels” for my non-UK friends), VS Code forces the developer to engage more with the stuff that happens around the code. You’ll find yourself editing config files a lot more than you would in Visual Studio too, which also helps to demystify the whole experience.

The bleeding edge can be pretty rough…

But while “demystifying” and “reconnection” sound great, there’s obviously a less glamorous aspect – there are some pretty rough edges. For instance, occasionally Omnisharp will just stop working, leaving the developer bereft of red squiggles or Intellisense. Although restarting VS Code (which, as mentioned above, is mercifully much quicker than for Visual Studio) usually seems to clear these sorts of things up, I do find myself trawling through issues on GitHub from time to time.

When it comes to bugs and gotchas, it’s hard for this long-time Visual Studio user not to start making comparisons, but perhaps not always in the way you might expect.

In a day-to-day sense, I think the differences are typified by the experience of things going wrong. In Visual Studio I would rarely encounter issues with the tooling itself, but when I did I would be confronted with a cryptic error message. After some frustrated Googling, I’d frequently find myself on a UserVoice page along with a thousand other developers, but no sign of anyone from Microsoft. With VS Code, on the other hand, I do come across issues more regularly, but the resolution is usually easy to find. When there really is a bug, the response seems to be pretty rapid. In fact, I experienced this first hand when I had an issue with the .NET Core Test explorer .

When we think about the reasons for this, its a textbook case of closed- vs open-source:

• Visual Studio has the weight of a large professional team of developers and testers. These developers have almost total control over the way the major components interact and release batches of features and fixes periodically.
• VS Code is also developed at Microsoft but is open-source and (as mentioned above) has much of its functionality delivered through independently developed extensions. Features and fixes are released almost continually.

The result is a huge difference in what it feels like to be a user of these two IDEs. Not that VS Code is inherently or objectively superior, mind you: there have been a few times in recent weeks where I’ve found myself yearning nostalgically for Visual Studio. Each developer will have their own preference based on their working style and experiences. Choice is a great thing and increased innovation will surely lead to improvements in both products. Fundamentally, it’s developers who will be the winners of this competition.

The .NET ecosystem

Taking a wider perspective on my work over the last decade, VS Code seems to be a great example of the incredible trajectory of the .NET ecosystem.

When I started using C# it was with Winforms, which meant I was basically locked into the world of Windows. It was a deeply unsexy way to Make Computers Do Things ™ and, to be brutally honest, it stayed that way for years. With time though, projects like Mono, Xamarin, and Unity opened up new frontiers. For me (and perhaps my view is skewed by the sort of work I do), the game-changers have been .NET Core and .NET Standard.

Today it feels like .NET truly exemplifies the old “write once, run anywhere” motto of Java. Whilst a .NET Standard library may still find itself supporting a desktop application on Windows, it might just as easily end up in a zombie game on Android, or powering a web application running on Linux, or even in the browser itself . The fact that I can now develop C# applications in an open-source IDE made out of Javascript is a stark example of how much the world has changed.

Wrapping up

When I started my new job, I actually had the choice to use either VS Code or Visual Studio. At this point, I hadn’t written a line of C# in over a month and was feeling pretty rusty. Add to that the usual bewilderment of a brand new codebase with alien conventions… well, it was a bit of an uphill battle. I don’t know what compelled me to decide to try VS Code, but I do remember walking home that evening convinced I’d made a mistake.

A month in and I’m so grateful for that moment of madness, that leap into the unknown. Using VS Code has forced me to re-learn things I’ve forgotten, dig deeper into things I’d taken for granted, and to step back and reflect on my craft.

So rather than viewing VS Code with scepticism, or as Visual Studio’s poor relation, I’d encourage all .NET developers to give it a go. Challenge yourself to a week of working in VS Code and see what you learn. At the very least you’ll end up looking at Visual Studio differently, but you may well (like me) end up a convert.

Have you switched from Visual Studio to VS Code? Is it something you’re thinking of doing? (Or perhaps you’ve spotted a mistake… sorry!) Let me know in the comments.