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.
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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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)
[+] [-] jammycakes|11 years ago|reply
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.
[+] [-] MrZipf|11 years ago|reply
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).
[+] [-] josteink|11 years ago|reply
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?
[+] [-] rsuelzer|11 years ago|reply
[+] [-] ryan-allen|11 years ago|reply
C# and Visual Studio are seriously good tools. I'm using Typescript and Angular, too. Good times!
[+] [-] rsuelzer|11 years ago|reply
[+] [-] zaphar|11 years ago|reply
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.
[+] [-] serve_yay|11 years ago|reply
[+] [-] mattchamb|11 years ago|reply
http://stackoverflow.com/questions/707107/library-for-parsin...
[+] [-] akandiah|11 years ago|reply
[+] [-] thallavajhula|11 years ago|reply
[+] [-] dclusin|11 years ago|reply
[+] [-] Negitivefrags|11 years ago|reply
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.
[+] [-] bhuga|11 years ago|reply
[+] [-] hey-there|11 years ago|reply
[deleted]
[+] [-] pionar|11 years ago|reply
[+] [-] ghuntley|11 years ago|reply
https://github.com/fsharp/FAKE
[+] [-] Rapzid|11 years ago|reply
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.
[+] [-] acqq|11 years ago|reply
[+] [-] O____________O|11 years ago|reply
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.
[+] [-] pvsnp|11 years ago|reply
[+] [-] bengali3|11 years ago|reply
looks like it
[+] [-] mattchamb|11 years ago|reply
[+] [-] michaelfeathers|11 years ago|reply
[+] [-] angersock|11 years ago|reply
:)
[+] [-] vortico|11 years ago|reply
[+] [-] wtetzner|11 years ago|reply
[+] [-] moron4hire|11 years ago|reply
In other words, I'd rather not build with GCC on Windows.
[+] [-] 72deluxe|11 years ago|reply
[+] [-] cssmoo|11 years ago|reply
[+] [-] voltagex_|11 years ago|reply
[+] [-] julbaxter|11 years ago|reply
[+] [-] MichaelGG|11 years ago|reply
[+] [-] tdicola|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] detay|11 years ago|reply
[+] [-] NoGravitas|11 years ago|reply
[+] [-] viggity|11 years ago|reply
[+] [-] edandersen|11 years ago|reply
[+] [-] cwyers|11 years ago|reply
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.
[+] [-] joshstrange|11 years ago|reply
[+] [-] gavingmiller|11 years ago|reply
[+] [-] bjnbb|11 years ago|reply
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.
[+] [-] runjake|11 years ago|reply
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
[+] [-] JetSpiegel|11 years ago|reply
https://github.com/Microsoft/msbuild/network
[+] [-] InclinedPlane|11 years ago|reply
[+] [-] 72deluxe|11 years ago|reply
I haven't had any problems with it; at least it doesn't sit there and silently fail like xcodebuild does on OSX sometimes!
[+] [-] LeonRobrotsky|11 years ago|reply
No, but at least I can try and fix any bugs I come across instead of hoping MS takes my complaint seriously.
[+] [-] blawa|11 years ago|reply
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)