For a while now, it's been pretty tedious for me to bootstrap new programming projects. I have to go through many steps to get my environment setup for a new project to use in VSCode. Especially if I want to keep things consistent across all of the different random projects I start working on.

So I finally decided to make something to do that for me: vscode-configurator, a CLI tool for quickly bootstrapping new projects.

Ewww, VSCode? 🤮

Let me get this out of the way: Yeah... I use VSCode. lol It's what I've been using for quite a while now. For all of it's weird quirks, I'm very familiar with how it works. I've tried many different code editors, but I always come back to VSCode.

I've never been a big fan of "highly specific" IDEs. Maybe someday I'll write about that, but the short of it is that I'm a crazy madman someone who works with many different languages. Yeah, I've been mainly doing things in C# for the past few years; however, I also like to toy around with other languages and my actual job doesn't even involve programming. ¹

I do use NeoVim too, but I just haven't been able to switch my programming stuff to it. It's kinda relegated to quick file edits and whenever I need to modify a config file on a Linux system. Will I ever make the switch for programming...

A general overview of the tool

So what exactly does vscode-configurator do? I guess you could probably compare it to create-t3-app? It's kinda the same concept, but not entirely.

Right now it only bootstraps a workspace for C# projects, but I do plan on adding other languages and scenarios. I'm mainly writing the tool for myself, so, of course, I'm going to focus on it first and it's very opinionated. It also doesn't create the actual C# projects, so the point of it is to initialize and maintain the workspace for VSCode.

In the case of bootstrapping a workspace for a C# project it will:

• Initialize git.
• Run dotnet new to create templated files:
  • A root solution file (.sln).
  • A .gitignore file that contains a lot of common files/paths to exclude from git.
  • A global.json file for specifying which version of .NET for the dotnet to use.
  • Optionally add a nuget.config file to specify other NuGet feeds.
  • Optionally add GitVersion to the project, so versioning information for compiled projects is derived from git.
• Create a settings.json file for VSCode to define some local settings to the project.
• Create a tasks.json file for VSCode that defines a lot of the common tasks (and inputs for those tasks) I use for C# projects.
  • Tasks like building, compiling, restoring packages, etc.

Running it looks like this:

Pretty cool, right? Not only that, but I also have another command that can be ran afterwards to add a C# project file to the solution file and the tasks.json file:

Now the project is added to the root solution file and I can now select it as an option when I run a task:

Pretty dank, right?

Honestly, this will help me keep things consistent across all of my projects. No more having to copy/paste files, manually add specific things, or forgetting to run that one specific command.

Techno Mumbo Jumbo

I wrote this in... Wait for it... C#. SHOCKER! I know, right?

You're probably thinking that this could have easily been a shell script or a PowerShell script. You'd be right. Where's the fun in that, though? It mainly gave me an excuse to learn some more of the ins-and-outs of writing something that's meant to be Native AOT compiled.

What's Native AOT in the C#/.NET world? ² You're basically compiling to native code and not the traditional Just-In-Time (JIT) code that .NET is known for. There's no need for having the .NET runtime installed to run it. There's still technically a runtime, but it's directly embedded into the binary and it's trimmed down.

This is like the third or fourth C# project I've done that targets Native AOT compilation in just the last few months. ³ I've been tinkering with Native AOT compilation for a few years now, but, with .NET 8, it's gotten to the point where it's a viable option. There are a lot of "limitations" when it comes to it, so there are a lot of things that you have to do differently than if you were to compile it traditionally.

One of those is interacting with JSON. Especially when you're trying to work with a JSON that you can't reliably know the schema for (Or it would take too much work creating classes for all of it lol). I ran into that with the tasks.json file whenever vscode-configurator csharp add-project is ran. Here are three methods I made to handle that, if you're curious:

• src/Configurator/External/VSCode/Tasks/AddCsharpProjectToTasksJsonAsync.cs
• src/Configurator/External/VSCode/Tasks/GetInputNodeById.cs
• src/Configurator/External/VSCode/Tasks/AddOptionToInputNode.cs

A lot of this is just a good learning experience for me. I'm able to learn more about how things work under-the-hood. Honestly if you're a C#/.NET developer, Native AOT compilation will help you understand how a lot of the nice things work.

Wrapping up

Like I said before, I'm mainly writing this tool for myself. I can't guarantee that it will be good for you; however, if you're interested in it, you can check out my GitHub repo for it here. I've also got pre-compiled binaries for the latest release here.

I don't know which languages/scenarios I'm going to add next. Maybe Rust or an infrastructure-as-code language (Terraform OpenTofu or Azure Bicep)? I want to also make it customizable, so you can add whatever you want; however, I'm not focusing on that yet and I'm not even sure if I will add it.