MSBuild is a nightmare to debug if you end up writing even moderately complex MSBuild project files. It doesn't help that VS has a completely different implementation of MSBuild which is subtly incompatible with the command-line MSBuild.

Also, setting up proper dependency tracking, so that builds are incremental, is considered an "advanced topic", and is extremely difficult to get right in the presence of various kinds of generated files in the build. In these cases, it is much, much slower than a modern build tool like ninja.

MSBuild being open source is going to save countless hours of building workarounds for bugs that have been acknowledged and gone unfixed, or debugging strange problems.

I'm happy to see that it's happened, but would have been much happier had it happened a year ago and saved me months of build system hell.

AFAIK, VS uses the same implementation of the MSBuild engine but has some sleazy (buggy) performance optimizations. Add the property DISABLEFASTUPTODATECHECK=1 to get the same behavior.

We found this allowed us to eliminate differences we saw and found hard to track down and infuriating:

https://msdn.microsoft.com/en-us/library/vstudio/ms171468%28...

Thanks!

For some reason, when I was wrestling with that problem, all I could find was other people on forums with the same problem, and an acknowledgement that MS tried to keep the differences minimal. (I think, too, that some of the larger discrepancies must have been fixed with newer releases of VS... I recall things breaking even with VS's regular build command, not just when debugging.)

Informative, thanks. I have never ran into problems like that so I wasn't aware of problems with it. Thanks.

Crusty old GNU Make can be made to be very fast, even for large projects. It does take a bit of doing, however.