You don’t want platform agnostic so much as the native build tool for .NET. To be precise you should look into MSBuild (.NET) and xbuild (mono). They are functionally equivalent and moreover use the same XML-based build files so you can theoretically handle both .NET and mono without any modifications. In fact, rake or ANT have to call out to MSBuild to actually build any .NET stuff so you are already using it — the most common MSBuild file ends in .csproj.

I will note that having done a pretty massive amount of MSBuild scripting I would really prefer ruby-based build scripts over XML-based build scripts. Turing-complete languages in XML are verbose.

I’m only tangentially familiar with node.js so I could be wrong but my impression is there isn’t really a build there — it is all interperted javascript. Now, you might have a script to call NPM to load your packages.

Another thing you might want to look at is psake — it is a powershell-based build system based on ruby’s sake. I’ve heard good things about it though I haven’t used it in anger as I can make MSBuild do what I need it to do.

Sounds like a job for make(1). It’s compiled to a native executable, so you don’t need to install anything, and can launch any other build tools you might need. If your builds are straightforward (no complicated dependency management or fragmented configuration specifications) then it shouldn’t be too hard to set this up. The only thing simpler would be to have a pair of build scripts (one for Windows and one for Linux) you check out with the source.

Well for .NET projects typically one uses Team Foundation Server – Build Server setup on the Windows platform.

I want to make sure I understand your questions correctly, but it would help if you also gave your base O/S your developing in too.

Although not completely independent, SCons is a Python based build tool that I’ve had very good experiences with. Python is pretty commonly available (more so than Ruby?) and the “build scripts” are simple Python files that are very easy to write and maintain.

In a .NET environment, however, I’d still recommend learning some of MSBuild’s syntax, as you will ultimately have to use it for some part of the process. (Theoretically you could go without it, but very few . NET devs are going to not be using VS, MonoDev, or something like SharpDevelop, and I think they all generate MSBuild project files.)

what generic build tools out there include their binary run-times… target-platform-agnostic tools

Above would violate principle of separation of concerns, and quite in a blatant way.

Think of consequences. Such a tool would also need to have a set of binaries for respective target platforms, for all of them and for everyone of them.

This would mean that besides providing build tool functionality, its developers would also have to invest their efforts into platform-specific binaries – design, programming, testing, maintenance, doing new features, bugfixes and testing them again and again and again, over and over again.

Now take a minute to think of long-term perspectives for such a tool. “It’s a competitive worls, everything counts in large amounts.”

While developers of our monster tool would struggle with specific glitches and pecularities of each and every target platform, over and over and over again, their competitors would have a great time providing extensions, enhancements and new features to build functionality, leveraging on the fact that cumbersome platform specific is covered by underlying third-part runtime.

Since you specifically called out Node.js as a platform target, I assume that everyone has that installed on their machines. In that case, have you looked at Grunt? I don’t have any real experience with it (I downloaded it, tried making a script, then realized that NPM does most of what I needed), but it appears to be a flexible build tool written on Node.