+972 52-548-6969
How would I build MsBuild...
In the Open Letter to Scott Guthrie David talks about copying the features from OSS projects, and bring MsBuild as an example. MsBuild is a project that reached feature parity with Nant, there is basically no technical reason that I know to prefer on over the other. NAnt has more tasks, but MsBuild has quite a few as well.
The problem is that feature parity is just that, not enough. Both Nant and MsBuild are xml based programming languages. Read the last sentence again, and you can probably tell what I don't like in both. A much better approach to this would have been to keep the same targets & actions model, but to skip the XML and go with an imperative language for the actual implementation.
Xml is nice because you can pharse it easily, but it is not something that is meant for human consumption. A better alternative would have been something like Rake, but on .Net. (About two years ago, I played with porting NAnt to Boo. Not the project itself, but the syntax. I got to the point where it was very readable and left it, don't think that there is anything left of the project anymore, although the sources should be up somewhere.) At any rate, this would have been a significant improvement over the existing technology, not just another feature-parity product.
Comments
Why do I get this feeling like I'm going to see Rake on .NET wrapped in a MSBuild task or something? A slow weekend perhaps? Like how LINQ makes it way into NHibernate... heheh. Brilliant BTW
Hi,
I'm not sure it would be nice or better to scrap the XML.
XML is good when you want to build configuration tools around the files. XML is more portable also.
And was not a goal of XML to create readable configuration files ? A well formed XML is easy to read even for non programmers.
Moreover If you use C# instead of Ruby (or keep Ruby) for a make system, you will end writing somekind of script. Rake looks like Ruby code but specialized to handle the build process, am I wrong ?
This is code instead of a declarative syntax.
Cheers.
The problem with using an imperative language for your project and build file is that integrating it within an IDE (whether Visual Studio or anything else) would be fairly brittle.
I actually think that's a very interesting idea about writing build scripts in Boo. I've had a few times where I've had to embed some C# inside a <script /> task of my NAnt tasks before anyways, because either I didn't think it deserved creating a custom task for, or I was just being lazy. :)
Either way, by using a simple language like Boo, you could leverage the power of the language throughout, maybe without necessarily having to write a custom task for that one-off thing you can't do very elegantly in XML. And even if you do write some custom tasks, they could be written in the same language as the build script itself, Boo.
Interesting...
I guess you don't like Binsor either?
Bil,
cough
https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-commons/Rhino.Commons/Tasks/Boo.cs
Richard,
" A well formed XML is easy to read even for non programmers. " - No,it isn't. XML isn't readable to programmers beyond the simplest syntaxes.
Feel free to open a SSIS Package and tell me what is going on there, from the XML alone.
"you will end writing somekind of script" - Yes, I will. There is a reason it is call a build _script_.
Not that i can personally add something valuable on the topic, but here is link to what Fowler has to say http://martinfowler.com/bliki/JRake.html
Comment preview