The problem with MSBuild is that it tends to get used for things for which it is not really designed.
MSBuild was originally designed as a file format for Visual Studio solution and project files, generally intended to be managed by a GUI. If all you are interested in is spitting out binaries, it works pretty well, and the fact that it adds a ton of extensibility is actually quite useful.
It becomes problematic though when people try to use it to manage their entire end-to-end build process -- running tests, generating reports, stopping and starting servers, manipulating configuration files and so on. When you get to that level you really need a proper scripting language with a clean, readable way of expressing loops, conditions and subroutines, and that's where MSBuild falls down -- XML is horrible for that kind of thing, and the declarative, task-based paradigm simply isn't flexible enough.
Unfortunately, because of the all too common insistence of many .NET teams on being spoon-fed by Microsoft, a lot of projects stick with MSBuild for their entire end-to-end build process regardless, simply because they believe That Is How Microsoft Wants You To Do It.
stick with MSBuild for their entire end-to-end build process regardless
We do this and couldn't be happier, and it isn't problematic at all. But that may be due to the fact that msbuild itself is used as the master and for a couple of other of things it excels at (typically 'build project X with all possible combinations of platforms/configurations/..."). Anything which is too far away from standard msbuild is done in C# (code wrapped in tasks which are built on the fly or sometimes through Codetaskfactory) or Python (because sometimes it's just easier to invoke Exec Command="python ....." than to figure out another way). When used like this you just get best of both worlds, imo. Though I agree I pushed for this solution in a not-so-objective way because I was familiar with both msbuild and C# and it would turn out to be much faster to implement than learning anothr build system.
It sounds like you're describing using MSBuild tasks as a shim around C# and Python scripts. While that wouldn't be my natural choice, I'd be happier with it than some of the implementations that I've seen.
When I talk about using it for the entire end-to-end build process regardless, I'm talking about people using it to do things that should really have been written in C# or Python, such as manipulating multiple configuration files. The result is often gratuitous quantities of copy and paste boilerplate code that can be very painful to maintain.
Another common problem with many MSBuild scripts is that they border on the unreadable. Besides the syntactic noise of the XML angle bracket tax, almost every line in almost every MSBuild script that I've ever encountered is hundreds of characters long for instance.
I'm talking about people using it to do things that should really have been written in C# or Python
I know: I hang out a lot in StackOverflow's msbuild tag. While I love figuring out all kinds of weird msbuild ways to solve some of the questions out there, you are completely right that often the entire problem would simply be solved by not using it in the first place or at least trying to stick to what it can be used for and in the way it is meant to be used.
Task running is more what Ant is for, isn't it? Maven is more of a dependency management tool than a task runner. A lot of Java projects use both tools together for builds.
I've never used it, but MSBuild sounds like Microsoft's version of Ant to me.
MSBuild has a lot of Ant-yness to it, yes. However, I quibble with your definition of Maven as a dependency manager--it has one (and the independent implementation that can work with Maven repos is Apache Ivy) but I've never seen a Java project use both. Usually somebody jams some sort of runner into a Maven project as a different build step or something.
Yeah... I've also worked on corporate Java projects with no Ant, Maven, nor hand-rolled substitute, where the build process was to download the dependencies' jars from the internet manually into /lib.
>MSBuild was originally designed as a file format for Visual Studio solution and project files, generally intended to be managed by a GUI.
This is its biggest failure. Like, if you use wildcards in a reference inside of MSBuild, Visual Studio (which just parses and loads MSBuild, not saving the semantics of the file) will happily turn those into a list of files and save the list, rather than the wildcard.
> Unfortunately, because of the all too common insistence of many .NET teams on being spoon-fed by Microsoft, a lot of projects stick with MSBuild for their entire end-to-end build process regardless, simply because they believe That Is How Microsoft Wants You To Do It.
This, however, is totally and completely unfair. People stick with MSBuild because there's no other option that works with Visual Studio. Whatever solution one uses must, must, must work with Visual Studio, or it simply won't get off the ground. This is why psake and FAKE are so underloved: because to actually Do Your Job, you need MSBuild, and those don't help with that pain point.
And that sucks. Maybe the kproj stuff will help. But while loads of issues with .NET come from that expectation of spoon-feeding from Microsoft, this really isn't one.
> This, however, is totally and completely unfair. People stick with MSBuild because there's no other option that works with Visual Studio.
This is only true for .csproj and .sln files, which are managed by the Visual Studio GUI, and which I've said are a fair and appropriate use for MSBuild.
It is not true for more general-purpose build scripts, which in addition to building the solution also do things such as run tests, prepare reports, hack configuration files, create zip bundles, deploy upgrades, stop and start servers, and so on. For .proj files, all you get from Visual Studio is the XML editor. In theory, you also get IntelliSense; in practice, IntelliSense for MSBuild files is something of an afterthought, and nowhere near enough to make up for the horrible lack of readability and maintainability.
In any case, in most projects that I've worked on, the .proj files were not included in the solution itself and had to be edited separately. On at least one project I was ordered to rewrite perfectly good and easy to read Python build scripts in MSBuild gibberish for no reason other than "that is how Microsoft wants you to do things."
Both of which are well worth considering. There was a UserVoice suggestion for Microsoft to support PowerShell as an alternative to MSBuild in Visual Studio [1] but it was declined, which was a disappointment.
Personally up to now I've used Python for my build scripts given the choice, but more recently I've been using Grunt/Node.js, and I think that's likely to be my go-to tool going forward. Its ability to watch a bunch of files and run targets when any of them change (e.g. Less/CoffeeScript) is one particular thing that's got me hooked.
I don't agree that people do stick to MSBuild scripts for their build processes - I have seen many .net shops and almost all don't do anything in msbuild because they don't know how.
I see things like ANT scripts and individual steps in things like TeamCity as being far more common.
MSBuild was originally designed as a file format for Visual Studio solution and project files, generally intended to be managed by a GUI. If all you are interested in is spitting out binaries, it works pretty well, and the fact that it adds a ton of extensibility is actually quite useful.
It becomes problematic though when people try to use it to manage their entire end-to-end build process -- running tests, generating reports, stopping and starting servers, manipulating configuration files and so on. When you get to that level you really need a proper scripting language with a clean, readable way of expressing loops, conditions and subroutines, and that's where MSBuild falls down -- XML is horrible for that kind of thing, and the declarative, task-based paradigm simply isn't flexible enough.
Unfortunately, because of the all too common insistence of many .NET teams on being spoon-fed by Microsoft, a lot of projects stick with MSBuild for their entire end-to-end build process regardless, simply because they believe That Is How Microsoft Wants You To Do It.