Library.Template: A git repo template for .NET development

It is amazing what the .NET SDK can enable you to build with so little code. But very soon you need to add a cloud build pipeline for CI builds and to validate PRs. You’ll want unit tests, and then you’ll want code coverage, and dumps when those tests hang or crash. You’ll need to figure out versioning. You may want to maintain a consistent coding style. Oh, and don’t forget analyzers to help guide you in the way of best practices and avoid common bugs.

Both as a software engineer at Microsoft and an avid OSS developer, I get a lot of experience setting up repos and pipelines. There are so many lessons to learn about what works well, and how to design the setup so that it will work both today and tomorrow when a new SDK comes out that would otherwise break your build. Microsoft has fairly uncommon requirements that include servicing some software for up to 10 years, so it’s vital that our repos are set up with as many external dependencies as possible pinned down so that we can reproduce the same build long after those dependencies are deprecated.

As I learn those lessons, I found I had to apply them to many repos. Each repo was more or less out-of-date with respect to certain patterns, and it was difficult to keep track of them all. I eventually decided to start a new repo that was for nothing but tracking all the best practices of repos where I could record all my ideas. But it became more than just a reference repo. It literally serves as a template for many new repos. I even developed a process by which existing repos can adopt its history into an existing repo’s history so that a simple git merge can update another repo as these patterns evolve.

The repo is itself OSS and I encourage you to take a look: AArnott/Library.Template: A template for a NuGet package with tests, stylecop, fxcop, versioning, and Azure Pipelines build ready to go. (github.com)

Your first reaction may be that the repo is surprisingly large for being just a starter without any code in it. The README in the repo explains some of the features and reasoning behind some of these files in more detail than I go into with this post. Every file and line in that repo has come from (sometimes painful) lessons learned in many other repos. Generally, I only add functionality to this repo when it is a common requirement for several other repos.

I hope you find it useful.

Related Posts

Are warning-free builds really a good thing?

I’m a big fan of pipelines that fail for warnings as well as errors. Such a policy keeps repos clean, current, less buggy, and even more agile….

Should I merge or rebase in git?

A lot has been said about whether folks should rebase, squash or merge into their git repos. It has almost gotten to the level of religious arguments…

All about RSA key formats

I’ve spent the past few weeks building up the PCLCrypto library which targets .NET Framework, Windows Store (WinRT), Windows Phone (WP8), Silverlight (SL), Xamarin.Android (XA) and Xamarin.iOS…

Moving on… DotNetOpenAuth in search for new project leaders

Disclosure and disclaimer: I am a software engineer at Microsoft, but the following post (just like all other posts on this blog) is my own and in…

How to get meld working with git on Windows

Inspired by these instructions, I followed these steps: Install Python 2.6 Install PyGTK All-in-one installer Install meld Then you need to configure git to be able to…

Immutable collections with mutable performance

In my last post, I detailed the differences among read/write, read only, frozen and immutable collection types.  I described how immutable collections come with a hit to…