
MSBuild is now open source on GitHub - pauljz
http://blogs.msdn.com/b/dotnet/archive/2015/03/18/msbuild-engine-is-now-open-source-on-github.aspx
======
jammycakes
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.

~~~
raverbashing
> XML is horrible for that kind of thing, and the declarative, task-based
> paradigm simply isn't flexible enough.

Of course! That's why the Java world uses maven

It makes no sense, but hey, it's XML

~~~
kyllo
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.

~~~
eropple
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.

~~~
kyllo
_Usually somebody jams some sort of runner into a Maven project as a different
build step or something_

Like this? [http://maven.apache.org/ant-tasks/](http://maven.apache.org/ant-
tasks/)

~~~
eropple
If you're lucky. I've seen a lot more home-rolled ones in Java.

~~~
kyllo
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.

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

~~~
stinos
_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.

~~~
MrZipf
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.

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

~~~
ryan-allen
As a .NET developer who has wholly abandoned Ruby and it's culture, I'm having
the time of my life!

C# and Visual Studio are seriously good tools. I'm using Typescript and
Angular, too. Good times!

~~~
ghuntley
This * 10000.

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

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

------
mattchamb
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...](http://stackoverflow.com/questions/707107/library-for-parsing-
visual-studio-solution-files)

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

------
arrowgunz
Licensed under MIT, impressive.

~~~
ghuntley
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!

Fancy that, how times have changed.

~~~
masklinn
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.

~~~
hyperpape
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.

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

~~~
Negitivefrags
I 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.

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

------
ghuntley
MSBuild 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
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.

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

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

~~~
cssmoo
_> 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.

~~~
O____________O
_Do you run VS on your production servers?_

Why would I have any build system installed on a production _server_?

~~~
snuxoll
For CI? Gotta run your builds somewhere, and a build agent is a production
application.

~~~
O____________O
What is CI?

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

~~~
mattchamb
Interestingly, Roslyn already includes its own parsing/handling of visual
studio solution files:
[http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Wo...](http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Workspaces.Desktop/Workspace/MSBuild/SolutionFile/SolutionFile.cs,102)

~~~
ygra
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.

~~~
khellang
See
[https://github.com/dotnet/roslyn/issues/212](https://github.com/dotnet/roslyn/issues/212)

------
michaelfeathers
It would be poetic if they put up Visual SourceSafe.

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

:)

~~~
moron4hire
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.

~~~
angersock
Sure, 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.

~~~
moron4hire
Ok! Thank you. I think that makes a lot of sense.

~~~
angersock
No problem.

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.

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

~~~
dietrichepp
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.

~~~
voltagex_
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.

~~~
ihnorton
CMake supports VS2012-2015 natively in the latest releases.

------
julbaxter
What's the difference with Roslyn?

~~~
MichaelGG
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.

~~~
julbaxter
Does it mean msbuilb uses roslyn somehow?

~~~
MichaelGG
I understand that Roslyn powers or is the C#/VB compiler. Yes, the build
system will often call the compiler as part of the build.

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

~~~
NoGravitas
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.

~~~
floatboth
I'm working on a pretty advanced solution right now (F# + PCLs), everything
works both fine both in VS and Mono's xbuild.

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

~~~
cwyers
> 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
The reasoning is likely that there is now an internal KPI for open sourcing
code because it helps MS PR.

~~~
cwyers
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.

------
steveklabnik
The, uh, first PR:
[https://github.com/Microsoft/msbuild/pull/1](https://github.com/Microsoft/msbuild/pull/1)

~~~
acdha
I 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

~~~
robashton2
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.

~~~
acdha
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”.

------
nickbauman
What the hell is MSBuild and why should I care?

------
edandersen
[https://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
The 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
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?

~~~
dragonwriter
> 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/)

