I’ve done my fair share of bigging up Visual Studio Code in the past for being a great IDE and, well, it still is. It’s my go to coding tool for working on open source projects and it’s flexible enough to seemingly handle anything you can throw at it – including .NET, aparently.

Over the last couple of days I’ve been sharpening my .NET claws again, something I’ve not really touched for a couple of years. This is mainly because I think it’s healthy for developers to have several tools in their toolbox, even if they don’t really use them all the time – sure, I’m a PHP developer first and foremost but there’s likely to be a project I’m going to have to break out some C# in down the line and need to be prepared for that.

One of the things that stood out in the documentation on the Microsoft site is that there is guidance for using VS Code as your IDE when building .NET projects – check it out here. I thought I’d give it a go and, sure – it works great! To a point…

Okay, so off the bat, using VS Code in this instance requires a LOT more command line stuff than just using full fat Visual Studio – and that’s fine. As an open source developer I expect a certain amount of command line tomfoolery in my workflow. It’s fine. I will say, however, that the amount of command line interference needed to get a project working at different intervals isn’t entirely as intuitive as I’m used to. So that’s the first strike against Code.

The big roadblock came with the model instantiation, however; for some reason the scaffolding wasn’t working and I was running into numerous command line issues. Okay, so I’m sure there was a solution, but part of this exercise was to see just how easy it would be to use VS Code as a single IDE for projects using .NET and, when I hit this roadblock my immediate thought was “Why am I doing this?” I have Visual Studio set up on my PC so I loaded the project into that and continued the process without stress using the built in tools there.

Okay, so it’s shown me one thing, that the tools are comfortably interchangable, and that the code editor itself behaves the same way between each environment, but there is certainly something about using the right tool for the right job. Sure, I can smash a screw into a wall using a hammer but a screwdriver is going to do the job better and likely easier, so why not just use that?

Going back to my earlier thought – it’s fine to have tools that you don’t use all the time, so long as you know when it’s right to get them out of the toolbox and put them to work. I don’t use full fat Visual Studio for everything – on a whole I do find it to be somewhat overstuffed, but when it’s pointed at the right project it does the job just fine.