Live data from Hacker News

MSBuild is now open source on GitHub

blogs.msdn.com

141–150 of 185 posts

Re: MSBuild is now open source on GitHub

#141
post #115

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.

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…

My GitHub handle is the same as my HN username. Go nuts. You'll notice I mainly write .NET software but I won't be contributing to MSBuild. MSBuild is becoming irrelevant with ASP.NET 5 and Roslyn.

Re: MSBuild is now open source on GitHub

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

Re: MSBuild is now open source on GitHub

#143
post #142

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 so…

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.

Re: MSBuild is now open source on GitHub

#144

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 thoug…

stick with MSBuild for their entire end-to-end build process regardless

We do this and couldn't be happier, and it isn't problematic at all. But that may be due to the fact that msbuild itself is used as the master and for a couple of other of things it excels at (typically 'build project X with all possible combinations of platforms/configurations/..."). Anything which is too far away from standard msbuild is done in C# (code wrapped in tasks which are built on the fly or sometimes through Codetaskfactory) or Python (because sometimes it's just easier to invoke Exec Command="python ....." than to figure out another way). When used like this you just get best of both worlds, imo. Though I agree I pushed for this solution in a not-so-objective way because I was familiar with both msbuild and C# and it would turn out to be much faster to implement than learning anothr build system.

Re: MSBuild is now open source on GitHub

#145
post #143
post #142

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 so…

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.

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.

Re: MSBuild is now open source on GitHub

#146
post #64

Earlier quoted context omitted.

What's wrong with MSBuild/XBuild? 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.

MSBuild is a nightmare to debug if you end up writing even moderately complex MSBuild project files. It doesn't help that VS has a completely different implementation of MSBuild which is subtly incompatible with the command-line MSBuild. Also, setting up proper dependency tracking, so that builds are incremental, is considered an "advanced topic", and is extremely difficult to get right in the presence of various kin…

AFAIK, VS uses the same implementation of the MSBuild engine but has some sleazy (buggy) performance optimizations. Add the property DISABLEFASTUPTODATECHECK=1 to get the same behavior.

We found this allowed us to eliminate differences we saw and found hard to track down and infuriating:

https://msdn.microsoft.com/en-us/library/vstudio/ms171468%28...

Re: MSBuild is now open source on GitHub

#147
post #128

Earlier quoted context omitted.

Interestingly, Roslyn already includes its own parsing/handling of visual studio solution files: http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.Wo...

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.

See https://github.com/dotnet/roslyn/issues/212

Re: MSBuild is now open source on GitHub

#148
post #144

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 thoug…

stick with MSBuild for their entire end-to-end build process regardless We do this and couldn't be happier, and it isn't problematic at all. But that may be due to the fact that msbuild itself is used as the master and for a couple of other of things it excels at (typically 'build project X with all possible combinations of platforms/configurations/..."). Anything which is too far away from standard msbuild is done i…

It sounds like you're describing using MSBuild tasks as a shim around C# and Python scripts. While that wouldn't be my natural choice, I'd be happier with it than some of the implementations that I've seen.

When I talk about using it for the entire end-to-end build process regardless, I'm talking about people using it to do things that should really have been written in C# or Python, such as manipulating multiple configuration files. The result is often gratuitous quantities of copy and paste boilerplate code that can be very painful to maintain.

Another common problem with many MSBuild scripts is that they border on the unreadable. Besides the syntactic noise of the XML angle bracket tax, almost every line in almost every MSBuild script that I've ever encountered is hundreds of characters long for instance.

Re: MSBuild is now open source on GitHub

#149
post #138

Earlier quoted context omitted.

You will lose that feeling after 30 years. I have no special place for ZX Spectrum Basic anymore.

... Whereas I still love BBC BASIC and 6502 assembly. Some things are classics that will never go out of style.

I 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.
Post reply on HN