Yet Another Blog

Developer Tools to Install - 2020 Edition

Since I'm starting a new role with ChemVM, I decided to document what I install on a new dev machine.

For this go around, I switched from a Dell Precision 5530 to a Thinkpad X1 Extreme Gen 2. I may document my experience with that switch elsewhere, but suffice to say I really like everything about the Thinkpad, with the possible exception of where they put the Fn key.

First up, the basic stuff to install.

Microsoft Edge

I've mostly switched to using Microsoft Edge (chromium) for my daily browser and for development.


My previous default browser, I still love Firefox. Gotta at least have it for testing.


I install Chrome mostly just for testing/debugging.


We are running Microsoft 365 Business Standard.


I use npp every day for editing all kinds of text files.

Windows Terminal

The new Windows Terminal

Visual Studio

Next is Visual Studio. Since we are a startup, I'm giving Community edition a go. Community is more or less the same as Professional, and is free for 5 users in an organization with less than 1 million in revenue.

Here's the workloads and extensions I install:

Visual Studio Code

While I still prefer the full Visual Studio, I use Code for smaller projects, editing this blog, and such. Download here.

nodejs LTS

For Angular FE development among other things. Download here.

GitHub Desktop

I've been using this less and less as the git tooling in VS and VSCode get better, but I still use it from time to time. Download here

Git for Windows

Download here

Azure Storage Explorer

I Storage Explorer to manage Azure Storage accounts, transfer files, manage folders, etc.

Azure CosmosDB Emulator

This applies because we are using CosmosDB. You can download the emulator here.

Ubuntu via Windows Subsystem for Linux (WSL)

I use WSL mostly for testing .NET Core on Ubuntu. I used to use it and putty for ssh, but now that ssh is baked into Windows 10, I don't need to.

NuGet Package Explorer

For inspecting nuget packages. Website

Paint .NET or PhotoShop or Photoshop Express

I've used both Paint.NET, real Photoshop, and Photoshop Elements over the years. Recently, I've found for most of what I


For manipulating SVG files, I use the InkScape vector graphics software


Today marks the last day of a 9 year journey with csg. Next week, I'll be starting a new journey as the CTO of ChemVM Technologies. You can find out more about us here.

It's been a great ride a csg, and you should check them out if you need a technology partner for data analytics, business intelligence, custom software, and lots more.

Creating a Solution Template for the .NET Core CLI

Consistency is important in software development. From folder names to variable names, the more consistent a codebase is, the more easy it is to work in. At csg we aim to have a consistent approach to different custom software applications we build for our clients. One of the early ways we practice this is by starting each new git repo with common set of files and folders. Until recently, the workflow to accomplish this has been to clone what we call the "Skeleton" repo for a particular project type (API, website, class library, etc.), and then do a bunch of renames of namespaces, folders, etc. It turned out to be really easy to take our existing "skeleton projects" and turn them into custom templates for dotnet-new.

While there are many freely available templates for dotnet-new, we find it useful to have a lot of the boilerplate we would build out directly in a template.

A typical skeleton structure we might use for a website use looks something like this:

  • build
    • repo.props
  • src
    • Skeleton.Classlib1
    • Skeleton.Classlib2
    • Skeleton.Website
  • tests
    • Skeleton.TestProject1
    • Skeleton.TestProject2
  • .gitignore
  • azure-pipelines.yml
  • build.ps1
  • Directory.Build.props
  • SkeletonWebsite.sln
  • version.json

This structure is similar to (and was mostly ripped off from) some of the ASP.NET repo structures circa 2017. I won't go into what all these files are in this post, but most of the meat is in the src/ folder, where various class libraries and other projects go. Some solutions have lots of projects, some have only a few. The contents of the various files in the project might look something like this:

using System;
namespace Skeleton.Api.Controllers
     public class WidgetController : ControllerBase
        private readonly ISkeletonRepository _repo;

        public WidgetController(ISkeletonRepository repo)
       	    _repo = repo;

Note that the code contains classes, interfaces and other identifiers containing the word Skeleton. To turn this structure into a template, first I added a folder named .template.config, and inside place a file named template.json which looks like this:

  "$schema": "",
  "author": "Justin R. Buchanan",
  "classifications": [ "ASP.NET", "Website", "Solution" ],
  "identity": "Csg.Templates.AspNetCore.Website",
  "name": "CSG ASP.NET Core Website Solution",
  "sourceName": "Skeleton",
  "preferNameDirectory": true,
  "shortName": "csgaspnetweb",
  "symbols": {
    "title": {
      "type": "parameter",
      "datatype": "string",
      "replaces": "PROJECT-TITLE",
      "isRequired": true,
      "description": "The display name used in assembly info and as the default website title"
  "sources": [
      "modifiers": [
          "exclude": [

The important bits above are sourceName, which is used to search and replace file contents, and shortName, which is used when creating an instance of this template from the CLI. After publishing this template, developers will be able to create instances using the dotnet cli as follows:

dotnet new csgaspnetweb -title "My Test Website" -output Test

The above command would produce a folder structure similar to above, but would have renamed the word "Skeleton" in all file contents, file names, and folder names with "Test", and renamed all instances of PROJECT-TITLE with "My Test Website". In addition, it would ignore .git and .vs folders. Once a template is created the way we want it, I publish the template to our internal NuGet feed using Azure DevOps CI/CD pipelines. Developers can then install or update their templates using dotnet new -i [template-package-name].