Hacker News Reader

Comment by edandersen | Hacker News Reader

Nobody is seriously going to fork this and create their own port of MSBuild, possibly one of the most mocked and reviled parts of the .NET ecosystem. I do however congratulate the ground level MS staffers on the effort it likely took to convice the Risk and Legal departments that open sourcing something like this won't make their business fail. That must have been trying.

View on HN

> Nobody is seriously going to fork this and create their own port of MSBuild, possibly one of the most mocked and reviled parts of the .NET ecosystem.

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.

The reasoning is likely that there is now an internal KPI for open sourcing code because it helps MS PR.

I doubt that it's anything as ephemeral as "public relations" that's driving this. They want developer mindshare. Having developers writing for .NET means more software available for Windows users and for Azure services. That means more people buy Windows devices and Azure time.

Will no doubt help realize the synergies and strategic alignments that were previously synthesized by Nadella.

It's not just PR. Open sourcing brings real benefits—look at the development around LLVM.

Good tooling helps everyone.

Yeah; I've had to deal with MSBuild, and I've never really liked it. I have to assume that the big motivation was that they'd prefer to port MSBuild to OS X and Linux than to port MS solution files and MS project files to CMake, Automake, or some other build system.

I haven't gotten past the point of where I just hit Ctrl-F5 and Visual Studio builds stuff for me with MSBuild, so I am certainly no expert on it. But I never had the impression that people liked CMake or Automake either. I ask this not as a rhetorical question but as an actual one: are there build systems that aren't hated, or does everyone just hate the one they have to use the most?

I like autotools more than MSBuild if that's any reference...

I admit this is biased, heavily so in fact, but most of what I know about autotools comes from this:

http://voices.canonical.com/jussi.pakkanen/2011/09/13/autoto...

Which... the reason it sticks out with me is that really good rants are a lot more memorable to me than people talking about what software they like, which is probably not a fair way to evaluate software.

I liked https://www.varnish-cache.org/docs/trunk/phk/autocrap.html myself.

Building using a keyboard shortcut from within an IDE is just one of the many tasks a build system is required for. Another is setting up a build server that builds the projects on every checkin, deploys it on the various test servers and runs all the test suites. That requires the build system to be scriptable, idempotent (as in weird stale cache issues won't screw up your builds) and easily controllable from the command line.

MSBuild completely sucks at these tasks when compared to any free software build system such as Ant, Automake, CMake, WAF or dozens others. It was designed to be used in conjuction with Visual Studio and you very much feel the limitations of it when you try to use it from the outside.

SBT has issues (I'd say performance primarily), but works really nice for what it does, IMO. Virtually no configuration required (for a simple project you only need to specify dependencies and maybe import IDE plugins), scriptable in a full JVM-based turing-complete language (Scala), sane per-project dependencies (packages are cached globally for the user, but whitelisted classpaths are dynamically generated for each project), and a consistent design (SBT plugins are really just library dependencies of the build itself, for example).

I straight-up like autotools, even though it's a bit warty.

Everybody hates some aspects of some of them, in my experience. People also tend to have strongly held preferences in the build system department - it's a bit like text editors. I tend to view it as problem-dependent as to which system is better. If you're all java, you probably want a build tool designed for that language (for example.) Lisp has asdf and friends. My focus (cross platform C/C++ building) has led me to deal with autotools and CMake. I prefer CMake for 3 major reasons: 1) self contained - you just install CMake itself and you can handle all sorts of things (tar.bz2 decompression, file copying, directory creation, etc.) automatically and portably. No need to first install Python or Perl or... whatever for Windows. From a Linux/*BSD perspective, developing on Windows is like crossing the Sahara - you need to carry your own supplies. CMake packs a lot into a small, self contained package. 2) Learn one language and you're done. Would it have been better to go with something like lua? Probably, in hindsight (my opinion). However, compared to the mind bending complexity that is sh + m4 + automake + autoconf + ... CMake is (in my experience) quite a lot easier to get a handle on. 3) Wide support for many platforms/tools (Visual Studio, Xcode, ninja, make, Eclipse, etc.) from one common set of build definitions. The maintenance savings really add up if you need to support all those tools - Hunt and Thomas's DRY principle in action.

I'm a fan of CMake for C++ as well, but have also worked on projects that included C++, C++/CLI, and C# and unfortunately CMake support for .NET projects is close to non-existent (there is some, but it's woefully inadequate). I managed to get it to work, but in a very non CMake way (basically generating the .csproj files by replacing variables within the XML with the appropriate value).

As for MSBuild and VS - I thought that Visual Studio actually compiles things with devenv.exe, rather than MSBuild. I remember working on a project where I was trying to set up Jenkins CI to build our projects and MSBuild wouldn't work (because the environment wasn't set up correctly), but using devenv.exe instead worked perfectly.

The CMake language is just an atrocious mess, but that gets easier with time. The main problem with CMake on Windows is that it is really really slow for large projects (because it has to call back out to CMake to do all sorts of basic stuff) and that debugging CMake errors is horrifically hard (this has improved in recent MSVS generator integration, but I'm stuck w/ VS2008 still).

I was working on adding unusual steps to the build. Things like "run the Protocol Buffers compiler on these files" (which, in the end, I just did through a batch file), and making sure the solution could be built on our CI server (at the time, that was Cruise Control but we eventually switched to Jenkins). It was no worse than Apache Ant in my experience (but I'm no fan of Apache Ant).

The project I worked on was relatively new. Another project had been started in Visual C++ 6 and upgraded multiple times over the years. Occasionally, somebody would go through the solution file and project files to see if we were doing silly things because of this evolution (e.g., defining rules that weren't ever used). And we had two or three ways of setting paths so that developers could check out the code and build without worrying too much. Especially when it came to projects that needed DLLs from other solutions.

We were able to reduce the amount of annoying things to a tolerable level. I believe they moved to something like NuGet (for some things) after I switched jobs.

There is exactly one build system I have ever liked. It was the one they used at Google. Unfortunately it's not available outside of Google so I don't get to use it now.

However if it ever became available outside of Google then I would use it absolutely everywhere.

I think some javascript build systems are getting better, like Gulp. I'm starting to think that most build systems could/should be written in javascript from now on since you then have a scripting language that probably will run on most systems.

Yes. That is the rationale, one more component for an open and cross-plat .NET ecosystem. Also, @migueldeicaza asked us for it, so Xamarin/Mono could use it. It was these two things, together.

While I agree, having access to the source of your build tool can be invaluable for debugging odd issues. So while no one will ever want to fork this they may use it as reference and/or for debugging.

I definitely look forward to being able to check the source for all the things with zero meaningful documentation beyond a few old blog posts and a book.

Yeah, I've never written anything in .NET but I know from experience the pain of sub-par documentation. Thankfully most of the stuff that I work with is OS so I can always dig into the code if the docs are lacking. Glad that now .NET devs who use this can do the same!

The value isn't in creating a new version of MSBuild. The value is in getting PR's merged into mainline. If you've ever done any CI based work, you'll know how valuable this release is! (says the ex .NET developer)

What's wrong with MSBuild/XBuild?

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.

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

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.

> Nobody is seriously going to fork this and create their own port of MSBuild

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

> Nobody is seriously going to fork this

https://github.com/Microsoft/msbuild/network

I said "seriously".

At least two of those currently have branches checked out with the word "fix" in the branch name. I'd wager that the owners of those forks are using them to fix something, hence "seriously".

One of those two is my fork and yes I did it to fix something, but edandersen's point was more geared towards a real fork (i.e. something that takes the project into a different direction) instead of the fork that GitHub requires to send a PR.

I agree with him, we already have a bunch of popular .NET build tools other than MSBuild like FAKE, basing one off of MSBuild doesn't seem to add a lot of value imho.

I mean, it's not like people are forking gcc daily. Not all open source is valuable because of the forks.

People committing to gcc probably have workflows that predate github. I think there are many "forks" that are just done as fixes on a local machine then sent directly as a patch.

Sorry, I wasn't talking about forks the github term, I was referring to forking the project. It's useful to have open source available just for maintenance.

Msbuild is a fantastic system. But it's incredibly horribly documented so it's difficult to know how to use it correctly.

I wonder why they revile it? I have projects that build under it on the command line for when I want to do a scripted release build and not suffer VS2010 (I use it at work, out of my hands).

I haven't had any problems with it; at least it doesn't sit there and silently fail like xcodebuild does on OSX sometimes!

> Nobody is seriously going to fork this and create their own port of MSBuild

No, but at least I can try and fix any bugs I come across instead of hoping MS takes my complaint seriously.

Typical 'let me mock this because hating on MS on HN is cool'

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)

Given the abuse and name-calling directed at another person further down in this thread posting under his real name, combined with the persistent attacks on any comment that is perceived to be in any way a criticism of Microsoft, I can't imagine why anyone would ever post under their real name around Microsoft fans.

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.

Please don't divert my comment. His argument was wrong, it doesn't matter who he's mocking.

Do you mean the guy that made fun of the company for open-sourcing their product by posting a PR that completely replaces it with another tool?

He was being incredibly disrespectful and he got called out for it. If he wasn't being such a prick in the first place, maybe people wouldn't call him one.

> If he wasn't being such a prick in the first place, maybe people wouldn't call him one.

There we go. Posted straight from Redmond, no less.

I'm not sure where you guys get off calling another commenter "a prick" over and over again, along with other insults, for a joke pull request, given there is a long history of people (including pretty notably respectable people) creating them. I even listed some in another comment you guys can keep downvoting (because apparently my comments are worse than personally attacking other commenters): https://news.ycombinator.com/item?id=9229987

I was using the same wording that the other commenter used, because that's what he was. If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

It's a joke PR, sure, but he was being disrespectful. He was insulting everyone who has worked on the product because he feels it's crap. He's entitled to his opinion, sure, but at the same time, he didn't have to state it the way he did. Just because it was a joke PR does not suddenly excuse him from his actions. It's not like it suddenly makes things okay.

He straight up made fun of the product, in a disrespectful way, and was called out for it by the community. You are free to disagree, sure, but there's a reason people reacted the way they did.

And furthermore, my location and the company I work for are completely irrelevant to this discussion. I'd appreciate you not bringing them in. I speak for myself, not my employer.

Joke pull requests waste the time of people who have much better things to do and demeans the immense effort it takes to drag projects to open source at large companies. Being called a prick for doing prickish things is a very light response, and in a functioning culture (one of which which software developers rarely do more than pretend to aspire to, but that's nothing new) it might even be enough to teach him to not do so again.

You know the best part, though? I've probably perturbed more electrons on why MSBuild is a horrible build system, and how its integration with Visual Studio will happily destroy many types of changes in .csproj files, than most people here. My life is worse when I have to deal with it. But despite that, I somehow manage to not cape up for jerks who hurt people. Isn't that weird?

And not one of your "pretty notably respectable people" is a person for whom I had the time of day before you alerted me to their penchant for screwing with other people for fun. A list of meaningless names to buttress the case for hurting other people is remarkably unpersuasive.

My GitHub handle is the same as my HN username. Go nuts. You'll notice I mainly write .NET software but I won't be contributing to MSBuild. MSBuild is becoming irrelevant with ASP.NET 5 and Roslyn.

Is it becoming irrelevant for C++ projects though?

No. It's also very much not irrelevant if you build non-web software. (I do games with .NET, and that's not going to be replaced by the kproj stuff anytime soon. Which is kind of a drag, I like that stuff, but such is life.)

Reply on news.ycombinator.com