just checked out your ‘rubicant’ project on github… looks like great stuff! i’m probably just going to throw out what i’m playing with after a bit, and fork your solution so I can add on to it.

You bring up some good questions that I’m going to have to think through while playing with this idea.

In terms of any extra work that it would take to maintain a custom task and an msbuild object – they are separate objects. I am calling ‘yield @msbuild if block_given?’ where @msbuild is a var pointing to an MSBuild object.

with this in play, my custom task is all of 27 lines of code, and there’s not much else that I’ll have to do with it, if anything. I should be able to continue expanding the core MSBuild object without changing the task. this should let people have the choice of using the custom task or the generick task w/ the MSBuild class directly.

If anyone’s interested in seeing what I’m doing, it’s up on GitHub: http://github.com/derickbailey/Albacore/ – it’s still very much a work in progress, though… don’t expect it to be a great solution, yet. :)

In the end, I found that once you start having to pass information into your custom task, such as the sln file, build properties like Output dir and such, that having everything in a custom task just got too messy.

In your define, you just end up wrapping what is essentially a custom class with:
task :name => :dependencies do
#custom code
end

So why do all the extra work, violate SRP, etc just to end up with less clean and expressive code that could just be avoided by having the person using the task just write: write the task :name => :dependencies themselves.

Also, using your footask example, what if they do:

FooTask.new :name, [:dependencies] do
#some more stuff here
end

Where do you do the #some more stuff here part… before or after? Even better, since you’ve made this a custom task, will you ever really need to do anything inside the block?

These aren’t all answers that I have. Just things that I’ve been thinking about a lot.

For example:

MsBuildTask.new (:compile, [:call_first, :call_second], {:opt => ‘opt1′, :opt2 => ‘opt2′}) do

end

doesn’t feel as nice to me as eventually moving towards:

task :compile => [:call_first, :call_second] do
MsBuild.new(:opt1 => ‘opt1′, :opt2 => ‘opt2′)
end

In the end, I decided that letting Rake handle the tasks and just creating custom classes (or custom methods which wrap those classes) feels and looks much nicer than custom tasks a la NAnt.

Remember, once you get into Rake, you have the full power of an entire language behind you and it’s easy to take advantage of.