You're probably right. But it does mean there's one more part of the .NET ecosystem that potentially runs on Linux and OSX, and that's probably the reasoning behind this.
I just type "msbuild" (or press F5 in VS) and I get result .exe file in 0.2 second. On Linux I type "xbuild" and it's the same. You can use Visual Studio without even knowing msbuild exists. Just occasionally a pre-build or post-build script needs to be added.
Makefiles, Gradle or CMake are much slower and very complicated.
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.
Except only a little project known as Mono [1]
> possibly one of the most mocked and reviled parts of the .NET ecosystem
News to me, people generally seem to like it.
1. https://twitter.com/migueldeicaza/status/237615174863958016
I haven't had any problems with it; at least it doesn't sit there and silently fail like xcodebuild does on OSX sometimes!
No, but at least I can try and fix any bugs I come across instead of hoping MS takes my complaint seriously.
Can you name one build system that people like, and concretely compare how its better than MSBuild, please? Once you do that, please feel free to omit the perfunctory thank you to look unbiased.
Also, this would now be community developed, let me know your github handle and I'll see what contributions you made to make it better (oh wait, that would require actual work and give you 0 internet points)
Edit: I'm just going to point out that even this comment has been downvoted https://news.ycombinator.com/item?id=9230140
I'm not sure what you guys think this kind of nasty behavior benefits you or your favorite company, or why you believe people don't notice and aren't going to do something about it.
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.
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.
Of course! That's why the Java world uses maven
It makes no sense, but hey, it's XML
I've never used it, but MSBuild sounds like Microsoft's version of Ant to me.
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 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."
Better alternatives include: https://github.com/psake/psake & https://github.com/fsharp/FAKE
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.
[1] https://visualstudio.uservoice.com/forums/121579-visual-stud...
I see things like ANT scripts and individual steps in things like TeamCity as being far more common.
Seriously - I remember at one client there was a specific machine set up to edit the build on because it was the only one that could open the workflow editor without crashing. Why there was a workflow editor to edit MSBuild stuff I don't know but that's that world in a nutshell.
If Make was that awesome of a project, it would have evolved to cover the needs of most developers, however, some tools grew around it to "workaround" its limitations, and then the monster called autotools was born.
I consider MSBuild much less worse than autotools. I'm not yet a fan of any build tool to recognise that it's good, but at least I can tell that MSBuild is one that sucks the least.
That's my interpretation (and not my sentiment - I'd rather MS open-source tools like this than not).
:)
In other words, I'd rather not build with GCC on Windows.
So, my issue with CMake is that I usually run into it with annoying academic projects, or other weird shit--that doesn't matter, but what does matter is that the code quality tends to correlate pretty well with my personal rage.
When I try to run it on Linux, sometimes it'll just fail because reasons (looking at you, player-stage five years ago). When I try to run it on Windows, I have to fiddle with settings, rerun it a few times, and only grudgingly will it emit a project and directory for me.
And what it does emit? Almost never a properly organized project. Usually a project with a name like "Project1" and some rando layout. Usually I can't even figure out what #defines are being set, because it's hidden away.
I'd much rather people just write simple Makefiles (it can be done!), and a few VS project files, and be done with it. CMake has never once, in the last five years, ever resulted in me looking up from my machine going "Man, that was such a good experience, I'm sure glad we have CMake!".
The JS ecosystem, as crackheaded as it is, is still not 1000th of 1% of the annoyance as dealing with C/C++ using CMake.
Honestly, I don't know why anyone wants MSBuild. Poking around, people cite not needing to install the VS IDE on build servers, but I see zero drawback to doing that. Why would I want to maintain project dependencies, build orders, and whatnot in two places, when I could just build in exactly the same way, using the same solution/project files, on my dev box and my build server?
It seems to me that this is actually vastly more meaningful to traditionally open-source LAMP developers who are considering C# and ASP.Net on Linux in the future.
Do you run VS on your production servers? Because that's where it will shit a brick because you forgot to install ASP.Net MVC KB123123213 but the IDE installed it as part of update 4. Etc etc...
This problem gets VERY deep.
Why would I have any build system installed on a production server?
C# and Visual Studio are seriously good tools. I'm using Typescript and Angular, too. Good times!
Fancy that, how times have changed.
3 commits. Because MSBuild just happened.
The whole point of open source is that you get to go back and see how the software evolved. Git blame. Everybody learns.
Also, never before have I heard such an absurd claim as to what the purpose of open source is.
Let say you have the sources of an algorithm implementation, but they are unreadable because the variables are not named, you don't know the name of the algorithm getting implemented and so on. Of course this is a lot harder to understand than code which cites its references (like papers and so). Wouldn't this qualify as being able to "see how the the software evolved"? Granted, VCS history is only a small part of this, but I think it may help cause it would show what improvements were done, which shows the direction of the project, showing what's important. A large part of being a good programmer is knowing what NOT to do. If you see what others failed to do, don't you think that helps?
Its really not. Its a potential -- and perhaps significant -- side benefit of open source in some cases, but its certainly not the main motivation, much less the "whole point".
Or Blender?
Are they worthless because you can't see how it originally got developed?
MSBuild is essentially a clone ant, and it's not a bad tool per se. For the devdiv engineering team it allowed them to get off the horrible pre-msbuild project files.
The messiness came with solution files (since VS uses solution files and project files). Unfortunately, they left the also awful solution files around. And this added an alternate way to specify dependencies between projects. VS solution files are awful to maintain - just a bag of guids that makes resolving conflicts very hard for humans and VS is poor at automatically resolving them (very noticeable when you get >3 developers on a project).
The solution to the messiness would be to use an MSBuild project file instead of a solution file. It'd have to conform to a schema VS understands, but it's not rocket science. However, fixing this would require the VS source code and MSFT to accept a patch.
Using Visual Studio, gui or command line, uses the MSBuild engine though the VS wrapping does some internal caching that occasionally makes it wrong (ah! There's a cryptic flag that fixes this).
Indeed. Solution files are not only a terrible to work with in general, they are also unmergeable. They are the number one source of broken builds where I work whenever we do branching and merging. Everyone hates them.
Right now we have a two-layer hierarchy: Solutions, which contains projects (which are perfectly mergeable), and projects which contains code. Projects can depend on other projects, and must therefore also be present in the solution.
You thus need to redundantly express dependencies across solutions (which cannot safely be merged), and besides the academical (violating the DRY principle) this causes real world problems.
What would be neat was if we did away with solutions completely and instead you could have projects depend on other projects directly. And that was it.
Then you could create "solution-projects" by adding the actual project you wanted built, which which again might have their own dependencies and everything would resolve itself just nicely.
I'm pretty sure Eclipse already does this, so what's holding Microsoft back?
Read somewhere this is definitely on the dev team's list, but cannot find it anymore. When building a solution it is first converted to an msbuild file which is then built. So all that is left is to add VS gui support for such files to treat them as project containers, and then it's byebye sln.
looks like it
Having a company like Microsoft mentioning github all the time is great publicity.
Also bandwidth for hosting code is so cheap to be practically negligible.
This was inevitable from the announcement last year, but I'm afraid the community has not spoken on this, per say. One of the benefits of the open source community is that ideas get to duke it out in the wild and the most fit will survive. How long will we be saddled with msbuild? Maybe some brave heroes will create an alternative some day? There is a lot of legacy stuff that has not been properly vetted. Will be interesting to see what happens.
However the mono xbuild tool has subtle incompatibilities and holes in functionality as compared to msbuild so for no other reason than having the "same" build tool in mono and .Net I applaud this move.
http://stackoverflow.com/questions/707107/library-for-parsin...
