Designing a build system for .NET solutions with Cake - introduction

This is an update on my previous blog post "Smarter build scripts with MSBuild and .NET Core"

I previously touched on using updated features of MSBuild (15+) to improve the experience of maintaining a .NET Framework or Core solution. The focus was on centralising dependency versions and providing some smart defaults based on project types (i.e. unit tests should have standard set of packages, etc.)

For the past 4 years, I've advocated an approach to building and shipping .NET apps and services as something I call the "build submodule". That being a GIT submodule that can be pulled into your project, and provides a convention-based approach to building the projects within the parent repository.

For this blog series, I'd like to describe how to design such a build system, with some specific goals:

• Centralise dependency version management
• Build and pack .NET applications based on conventions using Cake
• Smart defaults on build options, such as compiler modes (Nullable), and analyzers
• Per-project overrides
• Versioning strategy using GitVersion and auto-tagging from your CI build

I'll also show how simple it can be to "update" your dependencies using the Build submodule approach, however it is not without its caveats. This is not a perfect approach, but an approach that has worked well for me.

I'll follow each blog post in the series with an accompanying  repository of a working model which you can play around with.

Contents

Issues in the series

1. The build submodule & Versioning dependencies
2. Build, test and pack .NET projects by convention using Cake
3. Build and pack .NET applications ready for deployment
4. Introducing build configuration options and smart defaults
5. Versioning strategy using GitVersion and auto-tagging from your CI build
6. Templating new .NET solutions from our build submodule