at least not that I knew of it.
A puzzled email told me that a Microsoft page lists me as an MSBuild blogger. I don't think I deserve that label.
Sure, I'm quite interested in MSBuild since I'm interested in build tools in general. And MSBuild looks both interesting and, errm, familiar to somebody who's been working on Ant for a few years now. But I haven't ever used MSBuild myself. I don't know whether it even runs on Mono, but I'd certainly be willing to give it a try.
path: /en/dotNet/msbuild | #
Since I get a lot of Google traffic by people looking for information on MSBuild, I should point to the new MSBuild homepage at Channel 9 as well as the Wiki (RSS 2.0 feed). Via Jomo Fisher.
path: /en/dotNet/msbuild | #
The MSBuild team is looking for a software developer experienced in build technologies and practicing an agile development style (via Chris Flaat).
Maybe one of my two readers qualifies for the job and even is interested.
path: /en/dotNet/msbuild | #
Junfeng Zhang points to a beta of an overhaul of MSDN.
I've been accessing the .NET class library docs at MSDN quite a bit over the past weeks and always thought it was rather hard to navigate - in particular when compared to the Javadocs I was used to. I later realized that many of my usability problems with MSDN go away when I use IE since MSDN's navigation frame works a lot better there. But I rather don't want to switch machines between coding on Linux/Mono and reading docs.
First impressions of the new site:
I can now go to the docs of the String class via http://msdn2.microsoft.com/library/System.String and even to String's Length property via http://msdn2.microsoft.com/library/System.String.Length. This is a lot better than anything that has been there before. It doesn't work for http://msdn2.microsoft.com/library/System.String.Equals, though, but let's remember this is a beta.
http://www.javadocs.org/string#length() is even more concise, but it took many years to finally get there.
- The text is finally readable in Mozilla and friends, although the code snippets and the navigation are still a point or two to small. In the "old MSDN" the first thing I did was hitting CTRL-+ to increase the font size.
- I still have to click on "Foo Members" to see the methods offered by Foo - one more click than I need in Javadoc.
- One single frame and no JavaScript magic to synchronize a bigger frameset, yay!
path: /en/dotNet | #
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 | #