8 ms·
MSBuild is now open source on GitHub
- pvsnp 12y agoThis is really exciting move. I wonder if this would make compiling the .NET core easier in OSX and Linux?
- bengali3 12y ago> 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. looks like it
- mattchamb 12y agoInterestingly, Roslyn already includes its own parsing/handling of visual studio solution files: http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Workspaces.Desktop/Workspace/MSBuild/SolutionFile/SolutionFile.cs,102 http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Wo...
- ygra 12y agoWhich 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.
- khellang 12y agoSee https://github.com/dotnet/roslyn/issues/212 https://github.com/dotnet/roslyn/issues/212
- dclusin 12y agoSort 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.
- Negitivefrags 12y agoI would bet that it helps github far more than it hurts. 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.
- hey-there 12y agoI know both MS and Google have contracts with GH and are paying 6 figure sums annually, but I'd better keep my source confidential.
- skeletonjelly 12y agoCan't you just give your confidential source the MIT license?
- bhuga 12y agoWe do not charge for hosting any open source project, large or small.
- edandersen 12y agoNobody 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.
- joshstrange 12y agoWhile 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.
- plorkyeran 12y agoI 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.
- joshstrange 12y agoYeah, 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!
- cwyers 12y ago> 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.
- edandersen 12y agoThe reasoning is likely that there is now an internal KPI for open sourcing code because it helps MS PR.
- serve_yay 12y agoI 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.
- steveklabnik 12y agoThe, uh, first PR: https://github.com/Microsoft/msbuild/pull/1 https://github.com/Microsoft/msbuild/pull/1
- markcerqueira 12y agoWell now, isn't Rob Ashton just one of the wittiest people on the Internet these days!
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- acdha 12y agoI wish he had a bit more empathy for whatever poor grunt at Microsoft had to slog through the process of open-sourcing it only to get this in thanks
- steveklabnik 12y agoI have incredibly complicated feelings about this whole topic, but I certainly agree with you.
- deleted 12y ago[deleted]
- AngrySkillzz 12y agoNot sure how comparable these are, really.
- robashton2 12y agoI 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.
- pionar 12y agoThe worst part of msbuild has (for me) been the lack of documentation of flags. Hopefully this will help.
- angersock 12y agoPerhaps we can use this to start making headway in the fight to get rid of make, autotools, and cmake? :)
- wtetzner 12y agoI don't think MSBuild is the solution.
- vortico 12y agoMake is just fine. I haven't found a case where it doesn't work, and it's almost always simpler than a mess of CMake and autotools.
- cssmoo 12y agoI hope you're joking. I've unfucked so much MSBuild cack in my time that it's not even funny now.
- 72deluxe 12y agoWhat about nmake on Windows? :-)
- moron4hire 12y agoI 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.
- angersock 12y agoSure, I'll bite. 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.
- nodivbyzero 12y agoC# again.... Not interested
- moron4hire 12y agoI'm curious what your motivation was to comment, then. Was it not obvious from the title what would be contained therein?
- nodivbyzero 12y agoc++
- anotherblue 12y agoMSBuild is used to build C++ projects, too :)
- zaphar 12y agoI 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.
- mattchamb 12y agoNice 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-parsing-visual-studio-solution-files http://stackoverflow.com/questions/707107/library-for-parsin...
- edandersen 12y agohttps://github.com/Microsoft/msbuild/commits/master 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.
- adamtulinius 12y agoThe historic commits might contain things unsuitable for relicensing. Also, never before have I heard such an absurd claim as to what the purpose of open source is.
- iso8859-1 12y agoI 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?
- dragonwriter 12y ago> 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. [0] http://opensource.org/about http://opensource.org/about [1] http://www.fsf.org/about/ http://www.fsf.org/about/
- julbaxter 12y agoWhat's the difference with Roslyn?
- deleted 12y ago[deleted]
- tdicola 12y agoThis 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.
- deleted 12y ago[deleted]
- MichaelGG 12y agoRosyln'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.
- acqq 12y agoReally great news! For those who didn't do Windows programming, the MSBuild is the "back-end" "make" engine behind the Visual Studio.
- O____________O 12y agoDespite 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.
- cssmoo 12y ago> 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... This problem gets VERY deep.
- michielvoo 12y agoYeah, 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).
- O____________O 12y agoDo you run VS on your production servers? Why would I have any build system installed on a production server?
- snuxoll 12y agoFor CI? Gotta run your builds somewhere, and a build agent is a production application.
- arrowgunz 12y agoLicensed under MIT, impressive.
- joshuapants 12y agoHas anyone at Microsoft put up a blog post about how they decided what license to pick? I'd be interested to read the rationale from a large company.
- ghuntley 12y agoAll 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! Fancy that, how times have changed.
- Sammi 12y agoWell FOSS people would say there is more freedom(tm) with LGPL2. But that's just like an opinion man.
- masklinn 12y agoWouldn'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.
- hyperpape 12y agoDepends. 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.
- voltagex_ 12y agoWill this help CMake's ability to generate solution files?
- dietrichepp 12y agoSolution 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.
- nickbauman 12y agoWhat the hell is MSBuild and why should I care?
- michaelfeathers 12y agoIt would be poetic if they put up Visual SourceSafe.
- rsuelzer 12y agoFantastic. 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.
- rsuelzer 12y agoNot that Ruby and Java are "bad". I just will always have a special place in my heart for c#, as it was my first language.
- bobofettfett 12y agoYou will lose that feeling after 30 years. I have no special place for ZX Spectrum Basic anymore.
- gaius 12y ago... Whereas I still love BBC BASIC and 6502 assembly. Some things are classics that will never go out of style.
- 72deluxe 12y agoI 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.
- bobofettfett 12y ago@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.
- akandiah 12y agoSimply 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.
- jammycakes 12y agoThe 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.
- ghuntley 12y agoThis * 10000. Better alternatives include: https://github.com/psake/psake https://github.com/psake/psake & https://github.com/fsharp/FAKE https://github.com/fsharp/FAKE
- jammycakes 12y agoBoth 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. [1] https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2193519-adopt-powershell-as-a-way-of-defining-build-script https://visualstudio.uservoice.com/forums/121579-visual-stud...
- raverbashing 12y ago
- ghuntley 12y agoMSBuild is great and all but seriously why bother when there's better alternatives available - i.e. Fake? https://github.com/fsharp/FAKE https://github.com/fsharp/FAKE
- Rapzid 12y agoI 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.
- MrZipf 12y agoIIRC 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).
- stinos 12y agoThe 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.
- MrZipf 12y agoThat'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.
- josteink 12y ago> 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?
- detay 12y agoWould this lead to a Visual Studio on MacOs/Linux one day? (I hope it would)
- NoGravitas 12y agoIt'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.
- floatboth 12y agoI'm working on a pretty advanced solution right now (F# + PCLs), everything works both fine both in VS and Mono's xbuild.
- viggity 12y agoVS 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.