How do you write an MSBuild task to support cancelation?

Question

I have a custom MSBuild task for xUnit.net. When the task is running, if I hit Ctrl+C, it 'tries' to cancel the task, but of course it fails (since my task doesn't support cancelation). No amount of MSDN doc searchs or Google-fu have landed on a solution. Since I can't find an obvious interface to implement, I'm guessing maybe cancelation is supported by way of some convention.

Has anybody done this before, and knows what's required to get cancelation to work?

Answer 1

I know you're well aware of the Task hierarchy, but on the offchance this is what you're looking for and it's just the fact that you're not implementing a ToolTask...

Inside MSBuild 2nd ed says (p118) of ToolTask.Cancel

This method is called to cancel the task execution. Once this method is called by MSBuild, if the task does not complete, it will be forcefully terminated

There are no other references to cancellation in it.

Answer 2

Your task needs to implement ICancelableTask. It's a very simple interface added in 4.0.

Basically you just add a Cancel() method. It must be ready to be called on a different thread, at any time, and return promptly. Your task must then return from Execute promptly. Typically you'd set a boolean flag inside Cancel(). Then inside your task you'd typically have a loop processing each input in turn -- for example, copying one file after another -- and in each iteration, check the flag; if it's true, break out. It doesn't matter whether you return true or false from Execute in this context.

If you're deriving from ToolTask -- if your task spawns a tool, it's very strongly recommended that you do this, as it saves a great deal of code, handles async logging, and other things -- then it already handles Cancel automatically. When Cancel happens, it kills the tool it spawned and all its children. The C++ team's tasks in some cases override this default behavior, so that their compiler/linker has a few seconds to clean up their half-written outputs before returning.

(Trivia: when I first implemented this in MSBuild, I accidentally made VS bluescreen the box occasionally. This nearly shipped in VS10 beta but was discovered just in time. The bluescreen was because the logic for figuring out the process tree was wrong, and would sometimes kill a system process. Oops.)

Dan