If you have the tiniest shred of affection for old-fashioned vinyl records, you have to love the 12″ singles created by New Order in the 80s. They have Peter Saville’s beautiful, minimalist designs, they sound superb, and the songs themselves still pack a punch. Yesterday I played Blue Monday followed by both versions of Ceremony … stunning. I don’t believe that vinyl has any magic properties; yet I have never heard CDs that sound as good.
The rise and rise of Eclipse, the open-source tools platform, is now an old and familiar story. It’s possible though that Eclipse adoption is nearing its peak. I’ve just received issue 43 of the EclipseSource newsletter, which includes the results of BZMedia’s November 2006 survey. Here are some snippets that interested me:
Although Eclipse clearly still dominates Java development, I’ve picked up some dissatisfaction among developers I’ve talked to at conferences. Some of the complaints are the variable quality of Eclipse plug-ins, difficulty in managing plug-in dependencies especially across a team, and the view that Eclipse is less productive than favourites such as IntelliJ IDEA.
I also note that “free” is not such an unique feature these days, and that the Sun-sponsored NetBeans is winning praise for advances in its Java tools.
Don’t misunderstand me; Eclipse is not under threat. But I would not be surprised to see further levelling off of its adoption curve, or even a small decline in the next year or two.
Now that the holidays are over, here’s some hardcore tweakery for Visual Studio 2005 developers. Visual Studio 2005 includes a completely new build system based on XML build files and a standalone build utility called MSBuild. Visual Studio project files are in fact MSBuild files. Open them up in a text editor and you’ll see that they begin like this:
<Project DefaultTargets=”Build” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>
You can also build entire solutions from the command line. Just open up a Visual Studio 2005 command prompt (an easy way of setting up the correct path and enviromental variables), navigate to the project directory, and type:
msbuild yourapp.sln
This is NOT dependent on Visual Studio, since MSBuild is actually part of the .NET Framework redistributable package. This means you can take your project files and build them on machines that don’t have Visual Studio installed, which can be handy for servers.
But what if you want to edit the solution build file? Curiously, solutions are defined in .sln files which are not msbuild files. When you run MSBuild against an .sln file, it actually creates a new in-memory build file for compilation, making it hard to edit.
This is where the tweak comes in. If you define the enviroment variable msbuildemitsolution, then MSBuild generates the solution build file and leaves it there for you to edit. It is given the name yourapp.sln.proj. For the next build, you can run msbuild against this file directly, thus incorporating any manual changes.
Why it works like this, who knows? Still, it’s an intriguing tip and as you can guess I didn’t discover it by accident. I got it from Sayed Ibrahim Hashim’s excellent blog. He is the author of the MSBuild/ClickOnce book Deploying .NET applications. I haven’t seen the book, but I recommend the blog if you want to know more about msbuild; the book is likely good as well.