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