Hoo boy, MSBuild was always by far my least-favorite part of being a .NET developer. I would like to flippantly say they should just throw it away and replace it, but probably much too late for that.
I have no strong opinions for or against MSBuild. What is it that you dislike about it? Or what is it that other tools do that MSBuild fails to do?
PS - I have done a lot of .Net development, but rarely did anything beyond the basics with MSBuild directly (mostly via Visual Studio, or took the pre-generated command line and stuck in a script).
I really hated the language you use to describe build tasks. It is a very frustrating mix of declarative and imperative syntax. And of course, who wouldn't want to write code in XML?! (XML, the markup language, the one we use for marking up information like documents and records.)
I was doing fairly complicated tasks with it years ago, and it's just one of those technologies that feels like it is fighting you at every turn. This was for continuous integration stuff and developer-productivity tools, not "open up Visual Studio and click the button". Thankfully much of that has been obviated over the years by things like NuGet and Octopus coming around.
> I really hated the language you use to describe build tasks.
Yup. For some reason that escapes rationality, MS chose to control the build through Workflow Foundation. And they build a horribly complicated WF "script". Pretty much universally hated.
But you may be pleased to know that they have now abandoned that, and each build task can now be described pretty much by the scripting language of your choosing.
Ah, that is nice. .NET seems to have a wonderful property where even if they start out with something dumb, they eventually come to their senses and do the right thing. Sure can take a while to get there, though.
cmake is certainly worth looking at. Doesn't take much to get up and running with it, it's pretty straightforward to use once you're set up, it takes out-of-source builds seriously, and it's got fair support for adding custom build tools (something you'll have a devil of a time getting working nicely in Visual Studio). Reasonable ecosystem as well, with a good supply of online examples and drop-in helper scripts for locating common libraries. (Compare and contrast to, e.g., MSBuild, boost jam, or JamPlus - all of which, even MSBuild, might as well by comparison have about 0 users each.)
Not to say that it isn't awful in many respects, though. It often feels as if it has been designed by 3 people, none of whom talk to one another, and all of whom have different ideas about how things should work. For every time there's some easy setting that nicely handles every platform for you there's another where you have to carefully distinguish between VC++/gcc/clang/etc. and add compiler-specific flags to some random string. And the scripting "language" is unhinged.
Still - compared to a normal project that targets N platforms, where you might well have to deal with N build systems, all appalling, if you use cmake, you'll only have to deal with one.
I hated it too. I don't recall a single good moment about using MSBuild. I never once felt like I'd figured it out, nor that I was getting to grips with it. But perhaps its brilliance was just beyond my ken.
It was astoundingly verbose, rather poorly documented (I didn't think much of the official book either), extremely short on any kind of examples that might be usable with slight tweaks when you're getting started, and seemed to make unnecessarily heavy weather out of the simplest of tasks. Your debugging options are rather limited (especially if something goes wrong in one of your DLLs!), and I for one found the log files very hard to read.
(On more than four occasions, I also lost a lot of source files after doing a build|clean. I never managed to finger MSBuild for this directly, but there aren't that many programs that are invoked on build|clean, and fewer yet that rely a filing system watcher to tell them which to delete, so I know where my suspicions lie.)
I also have vague memories of finding out that only certain constructs could be made conditional, and that there were no facilities for abstracting conditions, making some of my files very repetitive and long-winded - but to be honest, at this point, I've blanked most of it.
> PS - I have done a lot of .Net development, but rarely did anything beyond the basics with MSBuild directly (mostly via Visual Studio, or took the pre-generated command line and stuck in a script).
This is an excellent reason to avoid MSBuild. IDE lockin is a nightmare.
If you're making libraries, console applications or doing modern websites it's pretty easy to get your build working without Visual Studio.
One - ELEPHANT SIZE - problem is that for some reason Microsoft only ship the Windows SDKs as part of Visual Studio. Meaning that you'll need to install the IDE at least once to get a build running (you can copy the SDKs around after that).
Microsofties - I know that a lot of dev-div people will be reading - can you shed some light on this situation? What's the reasoning behind not shipping the SDKs separately. I've never had this problem with Java..
FWIW, you can install MSBuild without Visual Studio. It's part of the Windows SDK. If your target system is not supported, you have to run it on a supported system and choose the "Download for installation on a separate computer" option. Then copy the resulting msi and cab files to the server and run them. See http://stackoverflow.com/questions/12944502/build-asp-net-4-...
However, after I did this, I had to find build targets that Visual Studio installed and copy them from my workstation into the same directory on the server (i.e. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications).
Yup, that's how I make a build server: clean windows image, MSBuild, then copy the utils, build targets, reference assemblies etc over from a machine containing VS.
It's such a pain that a famous ex-Microsoftie started a connect request for it:
This works fine until you have to build a project with a 3rd party commercial library requiring licenses (.licx files). I just spent a week trying to put together a vagrant vm to build such a project finally giving up and adding visual studio to its provisioning script.
Agreed. However, Apple has a nasty habit of disabling features (such as power settings) and making the control software less and less friendly. I love my Airport Extreme it's software doesn't do everything that the OnHub software does. Some things I would really like is the ability to quickly see who/what is connected to my network, some history of connections, and even a way to tune QOS for specific devices (i.e. my Roku boxes should have more bandwidth than my phone).
Not giving equity strikes me as a tactical error, because the hurt feelings seem to be worth a lot more to him than the money he now has and apparently isn't interested in. I understand the justification for not doing it, but it seems like he's paying a different price for it now.
At least in Germany (I assume in Sweden it's the same, but IANAL) it is legally very involved to offer equity - this is the reason why it's highly unusual to have equity as part of the compensation.
I love Rich Hickey and I will watch any talk he ever gives. I believe I have seen them all at current.
Here's what drives me nuts about this one, though - it gets passed around a lot where I work, and people say how strongly they agree with him. There are real, concrete things he claims are not simple here! Things like for loops. And these people I'm talking about, they say they love this talk and then they say they love for loops. Really! I don't get it.
It's perfectly reasonable to agree wholeheartedly with his core idea (easy vs simple) but disagree with his particular pronouncements on what is and isn't simple. Which could involve for loops.
Now, personally, I don't have much to say about for loops one way or the other. But I do disagree with him on types, which can be far less complex than he intimates. System F, say, which largely covers F#, OCaml and Haskell, can be completely defined as a handful of self-evident rules. A single page for both checking and inference, if in somewhat dense notation. That's not complex at all, especially since it follows fairly naturally from the way the lambda calculus works even without types.
To me, that seems like a perfectly consistent view. Nothing forces you to take everything he says or leave it: you can find it accurate piecemeal. Take the mental framework but apply it with your own knowledge and experience and you could very well come up with your own conclusions.
Seems like the perfect way to use ideas like this.
It's one thing to recognize simplicity versus ease of use, it's a wholly different thing to apply it. Ease of use is what is most trivially observable by an end user. Actually understanding the nature of the problem domain and properly evaluating architectures beyond making sweeping inferences from what the interface looks like, that is significantly more difficult. Despite all the lip service that gets payed towards simplicity, most people do not want it and it will be met by derision and scorn if the simple solution imposes a higher learning curve or does not make policy and integration decisions for the user. Especially considering the culture of coding bootcamps, DevOps, "get shit done" and "move fast and break things" by and large promotes an anti-intellectualism that is in stark opposition to deeply evaluating problem domains so you can come up with simple solutions.
Right, and so what you get is people saying something is "simple" when what they really mean is that they like it. Which is of course not Hickey's fault, it just irks me for some reason.
Repeating my call for each HN post to have a new, separate comments section specifically for shitty comments about the page itself as opposed to the ideas contained therein
It's like the theory of HTML and CSS - content vs presentation. Much like HTML and CSS, reality is a blur of them both, but we can still aspire to separate them as much as we can.
