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

[josteink]

> 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?

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