I have this itch: current build systems for .NET are insufficient. Some are just plain cumbersome, others are just blind clones of cmake. The cmake influenced build systems are good for small projects but become unwieldy as projects scale in size.
Here are some of the automated build systems for .NET:
– msbuild
– xbuild
– nant
– psake
– cake
– fake
– albacore
At my day job, we make extensive use of VSTS, Visual Studio Team System. For my own projects, I use App Veyor. Both come with their own task-based build systems that work well within their own ecosystem but you can’t run those tasks locally on developer environment. You can use something like cake with those CI systems, but cake’s power is tied to globbing as most cmake clones like rake and cake are.
Globbing isn’t ideal when you have larger project repos, especially ones that didn’t give enough thought around folder structure. I’ve also run that pesky path too long limitation in Windows around globbing because of npm modules.
If you go all in with something VSTS or app-veyor, you’re kind of stuck in a bad place where you can’t deploy when those services go down.
All of this has caused me to question existing build systems for .NET and to an important question: Why do these build systems not take advantage of solutions and project files and allow for local and ci builds?
Even the new dotnet command line tool supports interacting with solution files. Between the solution file and projects, you can get a fair amount of metadata about your projects and the automatically perform tasks based on that metadata.
I’ve decided to write a tracer bullet project around this concept for this summer called: Fmg-BuildChain. The goal is to create a build system that takes care a bulk of the work for you while allowing developers to override the logic as needed and can be plugged into popular ci solutions such as app-veyor and VSTS. This would allow developers to use the tool for local builds and ci builds.
My theory is that this will cut down on the extra work of creating the same tasks for each new project. One trickier item is handling secure values for deployment. I think the first version will look at using key vault or KeePass to store those values.
It’s going to be an interesting summer. If you have any thoughts or suggestions, sound off in the comments below, on twitter, or facebook.
