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.
FireFox
My previous default browser, I still love Firefox. Gotta at least have it for testing.
Chrome
I install Chrome mostly just for testing/debugging.
Office
We are running Microsoft 365 Business Standard.
Notepad++
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:
- Workloads
- ASP.NET and Web Development
- Azure Development
- Node.js Development
- Data Storage and Processing
- .NET Core Cross Platform Development
- Extensions
- GitHub Extension for VS
- Open Command Line by Mads Kristensen configured to open Windows Terminal
- CSS Tools 2019 again by Mads
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
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
InkScape
For manipulating SVG files, I use the InkScape vector graphics software
ChemVM
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
{
[Authorize]
[ProducesResponseType(401)]
[Route("api/[controller]")]
[ApiController]
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": "http://json.schemastore.org/template",
"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": [
"\*\*/.git/\*\*",
"\*\*/.vs/\*\*"
]
}
]
}
]
}
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]
.