The problem with MSBuild is that it tends to get used for things for which it is not really designed.
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.
stick with MSBuild for their entire end-to-end build process regardless
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.
It sounds like you're describing using MSBuild tasks as a shim around C# and Python scripts. While that wouldn't be my natural choice, I'd be happier with it than some of the implementations that I've seen.
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.
I'm talking about people using it to do things that should really have been written in C# or Python
I know: I hang out a lot in StackOverflow's msbuild tag. While I love figuring out all kinds of weird msbuild ways to solve some of the questions out there, you are completely right that often the entire problem would simply be solved by not using it in the first place or at least trying to stick to what it can be used for and in the way it is meant to be used.
Task running is more what Ant is for, isn't it? Maven is more of a dependency management tool than a task runner. A lot of Java projects use both tools together for builds.
I've never used it, but MSBuild sounds like Microsoft's version of Ant to me.
MSBuild has a lot of Ant-yness to it, yes. However, I quibble with your definition of Maven as a dependency manager--it has one (and the independent implementation that can work with Maven repos is Apache Ivy) but I've never seen a Java project use both. Usually somebody jams some sort of runner into a Maven project as a different build step or something.
Yeah... I've also worked on corporate Java projects with no Ant, Maven, nor hand-rolled substitute, where the build process was to download the dependencies' jars from the internet manually into /lib.
>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."
Both of which are well worth considering. There was a UserVoice suggestion for Microsoft to support PowerShell as an alternative to MSBuild in Visual Studio [1] but it was declined, which was a disappointment.
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.
I don't agree that people do stick to MSBuild scripts for their build processes - I have seen many .net shops and almost all don't do anything in msbuild because they don't know how.
I see things like ANT scripts and individual steps in things like TeamCity as being far more common.
IIRC MSBuild was the brain child of Alex Kipman, father of Kinect and HoloLens. As legend tells it he lashed up a demo version over a weekend and pitched it successfully in the corridor shortly thereafter. The rest is history.
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).
> The messiness came with solution files (since VS uses solution files and project files).
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?
The solution to the messiness would be to use an MSBuild project file instead of a solution file.
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.
That's good news. I left MSFT last year and know some of the internal build toolsets have their own similar solution, but it's not integrated with Visual Studio.
Fantastic. As a .NET Developer, who has been forced into doing Ruby and Java development, I really miss the .NET framework and c#. I'm hoping that this move toward open source will help more open-source projects adopt .NET. C# is such a wonderful language and anything that helps make it more mainstream in the open-source community is a Good Thing.
@gaius: You love it in a way that you do projects with them now? That you would choose it over something "better" (Z80,68k assembler?)?
Or do you love the nostalgia, the feeling you had when you were programming your first computer and BBC Basic is a token for that which evokes this feeling?
Because I also have fond memories and a warm glow from ZX Spectrums and Amstrad CPCs. But I do not love Z80 assembler or Locomotive Basic.
I got to use a BBC when everyone else was using PCs but I still love BBC BASIC. Never got as far as 6502, but I still have the manuals and James Watts' book on BBC programming somewhere. Really really good stuff; good to see another BBC appreciator here on HN.
I have a hate/hate relationship with msbuild as a build tool.
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.
Simply one of the worst development tools that MS has put out. Its problem is that it's a hack-job - an attempt to make it in to a 'project' file that Visual Studio can load and also where one can treat as a traditional (n)ant-like build file. That's not to say that I think (n)ant is better, but it's certainly not hacky and far better documented.
All of the Microsoft technologies which have been open sourced over the last couple months have been under MIT which is really strange actually as Mono is licensed under LGPL2 which is actually more restrictive!
Wouldn't licensing under GPL limit their flexibility with respect to external contributions? They wouldn't be able to use that in proprietary product, or move the project's development back to a closed model.
Depends. Some companies use GPL with copyright assignment to control the project: you can use it as a wholly open source product, but the company has the right to do future development in a closed source way, embed it in proprietary products, etc.
I don't know if that's likely with a build tool, but it happens elsewhere.
Sort of off topic, but I've always wondered if github charges larger orgs for hosting their projects like this. It seems like google and and microsoft get tons of free bandwidth from github to the point of being unsustainable w/o charging.
I was curious to see what would happen with build systems when they first announced the open source/cross platform. Initially I figured maybe something like FAKE or scriptcs based so we could break away from msbuild and powershell. But then they announced cmake and now this.
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.
Despite being a Windows developer for 90% of my career, I have no idea why anyone uses MSBuild. I've created several automated build and deployment systems, but I always used the command line Visual Studio interface.
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.
Visual Studio uses MSBuild. csproj/vbproj files are MSBuild files. MSBuild will take an SLN file as an argument and do the same as Visual Studio would do with it when you load it and click build.
Given the age of projects I've worked on, and that it's unclear whether MSBuild is involved in VS's C++ compilation, I don't think your assumption is correct.
incorrect, the visual studio solution file has build configuration details that msbuild will not honour (e.g. you can specify certain build order parameters), as I found out recently with a project I took over. (I was wondering why building from the command line with ms build produced different results).
> I could just build in exactly the same way, using the same solution/project files, on my dev box and my build server
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...
Yeah, I prefer not to use the built in Visual Studio project templates. Best to always use bin deployed binaries explicitly installed from NuGet packages. In the future (later this year) we can also bin deploy the runtime (.NET Core) and base class library (Core FX).
> We will be adding Linux and Mac support soon (perhaps with your help!) so you can use MSBuild to build the open source .NET projects on your preferred platform.
Which is built on the MSBuild API. Which makes it a bit annoying to use without the pre-release Visual Studio right now, as Roslyn is built against an MSBuild assembly that doesn't exist on my machine.
I come from a Windows background. I've been having a need to do more C programs lately, and I have generally been trying to migrate more towards platform-agnostic configurations. I had started looking at CMake under the promise of a cross-platform build system, but now I see a lot of non-specific complaints about it. Is there something specific you can articulate that is wrong with CMake, and what alternative is there for someone who A) wants to build cross-platform, but B) with as native of tools as possible for those platforms?
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.
And to be fair, there are a couple of folks I trust who have had great success with it--and yet, I never seem to run into those projects when I need them.
Cool VR stuff by the way...hit me up if you'd like to BS about it sometime.
Solution files are easy. Project files (I think you meant project files) are not too hard, if all you want to do is build. Integration with Visual Studio is part of the equation, too.
From memory CMake was only producing VS 2010 project files which then had to be fiddled a bit to upgrade them to 2012 - so a version bump would be appreciated.
Rosyln's a compiler/framework for certain language tools or something like that. Msbuild is like a Make type tool that actually calls the compiler, passes in flags and input files, determines what else needs to get done, etc.
This is just the build system that powers Visual Studio projects. Rosyln is a compiler as a service that lets you compile and inspect .NET code programmatically with an API.
It's more likely that it would make MonoDevelop more strictly VS compatible. It already opens and saves .sln and .csproj files, but my understanding is that going back and forth between VS and MD can lead to problems.
VS is built with WPF and making WPF cross platform would be one hell of an effort. It sits on top of too many low level windows apis that it would be a ton of work.
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.
> 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.
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.
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?
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.
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).
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).
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 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.
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.
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 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.
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)
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.
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:
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.)
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.
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.
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!
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)
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.
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.)
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.
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.
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.
I got loads of time for that, but I've also suffered at the hands of MSBuild as have thousands of others so the PR seemed like a funny troll at the time.
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.
I don't disagree that people have problems with Microsoft products but I would just suggest asking yourself whether the people who went to the trouble of open-sourcing something are likely to want those problems to exist rather than, say, engineers trying to do what they can at a big, complicated company. Is it more likely that the person who reads a troll PR is going to say “I had no idea everyone wasn't happy with this!” or that their boss will say “See, I told you that releasing this was a waste of time”.
IMO the PR is not only disrespectful but also utterly wrong, from a technical point of view.
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.
PR are not the place for jokes. Developers have enough to do managing their projects, they don't need to waste time sorting through jokes.
You might say, "it's just one joke, what's the big deal?" One joke, attracts others. Everyone thinks they're funny and their joke with worth everyone else's time to read it. If PR become a place that's acceptable to make jokes, it'll be flooded with noise.
There's a well-established tradition of pull requests and issues being used for commentary and humor.
Here's a selection. The first one is by the founder CEO of a company with a ~$1B valuation that's prepping for an IPO and is very similar to the one everyone here is complaining about. The second one has comments from a couple well-known tech folks. And so on...
The girl represents MS being proud of itself for open sourcing something the two blokes consider irrelevant, as they head to the pub for a nice pint of Make.
That's my interpretation (and not my sentiment - I'd rather MS open-source tools like this than not).
You absolutely were being an annoying prick. The best thing you can do is own up to it and apologize. Definitely not what you're doing right now, what with the whole "jees, what is your issue" thing.
The reason he's so touchy about it is he's a narcissistic annoying prick. He only did it for attention since people pay attention to bullies, and it requires no work or intelligence unlike being paid attention to for contributing constructively. Call him out as an obnoxious bully and his ego can't stand it.
I think it is an interesting perspective. What would you say the purpose of open source is? If not purpose, you can call it an attractive property.
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?
> What would you say the purpose of open source is?
The Open Source Initiative has this to say: "Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in."
Recognizing that "Free Software" and "Open Source" are terms for essentially the same thing originating from groups with slightly different goals, the FSF says this about Free Software: " Free software is about having control over the technology we use in our homes, schools and businesses, where computers work for our individual and communal benefit, not for proprietary software companies or governments who might seek to restrict and monitor us." [1]
Seeing the past history of a project before the point at which it was opened is somewhat related, but not necessary, to the motivation cited by the OSI, and not, as I see it, even related to the FSF motivation.
> The whole point of open source is that you get to go back and see how the software evolved.
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".
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.