|
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. |
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.