MSBuild is now open source on GitHub
blogs.msdn.com
blogs.msdn.com
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.
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...
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.
Like this? http://maven.apache.org/ant-tasks/
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.
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.
I see things like ANT scripts and individual steps in things like TeamCity as being far more common.
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."
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).
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.
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?
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.
C# and Visual Studio are seriously good tools. I'm using Typescript and Angular, too. Good times!
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...
Fancy that, how times have changed.
I don't know if that's likely with a build tool, but it happens elsewhere.
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.
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?
That seems like an inaccurate description of what's happening: http://stackoverflow.com/questions/11932164/what-parameters-...
They're using MSBuild, they just don't know it.
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.
The change was explicitly to make it so that a C++ project file was an MSBuild script.
Visual Studio absolutely uses MSBuild for C++ projects.
looks like it
:)
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.
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.
Good tooling helps everyone.
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.
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.
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 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.
However if it ever became available outside of Google then I would use it absolutely everywhere.
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.
No, but at least I can try and fix any bugs I come across instead of hoping MS takes my complaint seriously.
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.
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...
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.)
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
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.
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.
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
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.
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 haven't had any problems with it; at least it doesn't sit there and silently fail like xcodebuild does on OSX sometimes!
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.
That's my interpretation (and not my sentiment - I'd rather MS open-source tools like this than not).
It's all just a bit of fun; there is no need to get directly insulting over it.
The fact that your nasty comment here got upvoted rather than flagged to death is really sad.
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...
https://github.com/saberma/shopqi/pull/409
https://github.com/h5bp/html5-boilerplate/pull/1074
https://github.com/ericf/yui3-gallery/pull/21
https://github.com/WhiteHouse/fortyfour/issues
https://github.com/joyent/node/pull/2472
But apparently now that Microsoft is using GitHub, everything is Serious Business™? Is there a dress code now, too?
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.
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?
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.
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?