from Hacker News

MSBuild is now open source on GitHub

by pauljz on 3/18/15, 8:08 PM with 173 comments

  • by jammycakes on 3/19/15, 6:47 AM

    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.

  • by MrZipf on 3/19/15, 7:52 AM

    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).

  • by rsuelzer on 3/19/15, 3:25 AM

    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.

  • by zaphar on 3/18/15, 9:22 PM

    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.

  • by serve_yay on 3/18/15, 8:56 PM

    I spent a lot of time with this thing in my career. I wish I had some nice things to say about it. But I'm glad it is open source.

  • by mattchamb on 3/18/15, 9:22 PM

    Nice to see this makes the old approach of using reflection to use msbuild internal classes to parse solution files obsolete.

    http://stackoverflow.com/questions/707107/library-for-parsin...

  • by akandiah on 3/19/15, 5:44 AM

    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.

  • by arrowgunz on 3/18/15, 10:10 PM

    Licensed under MIT, impressive.

  • by dclusin on 3/18/15, 8:39 PM

    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.

  • by pionar on 3/18/15, 9:03 PM

    The worst part of msbuild has (for me) been the lack of documentation of flags. Hopefully this will help.

  • by ghuntley on 3/19/15, 7:03 AM

    MSBuild is great and all but seriously why bother when there's better alternatives available - i.e. Fake?

    https://github.com/fsharp/FAKE

  • by acqq on 3/18/15, 9:43 PM

    Really great news! For those who didn't do Windows programming, the MSBuild is the "back-end" "make" engine behind the Visual Studio.

  • by O____________O on 3/18/15, 9:44 PM

    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.

  • by pvsnp on 3/18/15, 8:32 PM

    This is really exciting move. I wonder if this would make compiling the .NET core easier in OSX and Linux?

  • by michaelfeathers on 3/19/15, 2:16 AM

    It would be poetic if they put up Visual SourceSafe.

  • by angersock on 3/18/15, 9:13 PM

    Perhaps we can use this to start making headway in the fight to get rid of make, autotools, and cmake?

    :)

  • by voltagex_ on 3/18/15, 11:21 PM

    Will this help CMake's ability to generate solution files?

  • by julbaxter on 3/18/15, 9:26 PM

    What's the difference with Roslyn?

  • by detay on 3/19/15, 11:42 AM

    Would this lead to a Visual Studio on MacOs/Linux one day? (I hope it would)

  • by edandersen on 3/18/15, 8:54 PM

    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.

  • by steveklabnik on 3/18/15, 9:02 PM

  • by nickbauman on 3/19/15, 12:24 AM

    What the hell is MSBuild and why should I care?

  • by edandersen on 3/18/15, 9:25 PM

    https://github.com/Microsoft/msbuild/commits/master

    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.