Jeff of the MSBuild team asks what works for you when it comes to debugging a build. There probably are no hard-n-fast rules.
You really need your build system to output enough information to track things down and this requires the exact location of the error together with some contextual information at the very least. When we introduced <import> in Ant we soon learned that you really need the full stack of nested build files listed to understand what went wrong. It's not enough to say the error occurred in line 37 of build file foo/bar/baz.xml, you also need to know which build file imported that file at which line - recursively. The same applies to using the <ant> family of tasks.
It's probably easiest to locate build process failures if you have some kind of continuous integration system in place, it may help to identify the change causing problem - but then again the problem may be a server that's unexpectedly unreachable or just the time of the day.
Are there any more hints? You can tell Jeff since you don't have to register to post comments at his blog ;-)
In the comments Steve mentions that IntelliJ IDEA now supports refactoring of build files, scary.
path: /en/dotNet/msbuild | #
Jeff describes how the whole MSBuild team locked themselves into a room for a week in order to fix bugs. This process is known as Hackathon (not part of the Jargon?) in the open source world and Jeff lists the most important ingredients of it: laptops and pizza.
From what he describes they've been quite successful, getting their bug count from 437 down to 264. As a comparison, there are currently 241 bugs and 444 enhancement requests logged against Ant, but we probably could do away with half of them (if not more) if we'd use WONTFIX more seriously/realistically.
Jeff's entry also sheds some light on how the team works, even more so than the blog of some students participating in a program called "Explore Microsoft".
could testers and program managers even fix bugs?
I hope his question was rhetorical. How about testers doing pair programming with developers to write unit tests? The whole separation of non-coding testers and developers is a very traditional picture that I wouldn't expect at Microsoft. I somehow expected them to be more "agile".
we don't yet know how many new bugs we introduced, or how the regression rate compares to the usual scenario when only developers are working on the codebase
You don't have an automated testsuite that would catch your regressions?
It looks as if they enjoyed their week, as if the testers (Jeff is one of them) got closer to the code and all of them learned a lot. If they keep discovering best practices that way, unit tests and continuous integration should be their next stops.
path: /en/dotNet/msbuild | #
Leo writes about the different projects that try to build upon Ant and in particular on top of Ant's import task.
In a parentheses he suggests that there was a flamefest going on between Ant and MSBuild and points to my blog. I've already commented in his blog, but since people follow his link looking for some action, I must disappoint you, there is no flaming.
In internet time, MSBuild is old news. There has been quite a lot of bad blood on some of the very first published statements by Microsoft that compared MSBuild to (N)Ant, in particular the initial revision of Brent Rector's "Introducing Longhorn for Developers", but this has been rectified later by the people responsible for MSBuild.
I for one am very interested in MSBuild since it takes a few different angles to building stuff than Ant. While being rather similar at the surface, there are some philosophical differences between the two (three, we shouldn't forget NAnt here).
The items in MSBuild still interest me a lot and I've not given up the idea to get something similar along with pipes into Ant (1.7/8/9, who knows). Of course, I still believe that Ant's approach to dependencies is superior to MSBuild's file timestamp based mechanism.
path: /en/dotNet/msbuild | #
It seems that Alex Kipman, the MSBuild Program Manager, will start a blog.
Just trying to help John to increase the "peer pressure". ;-)
Alex subscribed to the developer lists for both Ant and NAnt when Microsoft announced MSBuild last year. He's done a lot to calm the situation by answering questions as well as correcting some statements made about Ant and NAnt by Microsoft Press.
I'm looking forward to read more from him.
path: /en/dotNet/msbuild | #
Jeff Callahan, a tester in Microsoft's MSBuild team, has started a blog. Welcome Jeff.
path: /en/dotNet/msbuild | #