This blog has moved to http://blogs.msdn.com/b/appfabric please update your links!
Even when AsyncCodeActivity.Cancel is called, the activity will still execute the EndExecute method, so it isn't immediately obvious why a second path of execution is necessary. Implementing this method is useful only when AsyncCodeActivityContext.MarkCanceled is implemented, which in turn is useful mainly when cancellation is meaningful for the underlying operation (i.e. if work already completed can be rolled back).
In order to implement cancellation in a useful way, do the following:
If no work needs to be rolled back when an AsyncCodeActivity is canceled, it is not necessary to override AsyncCodeActivity.Cancel.
Can you elaborate on what you mean by 'only when AsyncCodeActivityContext.MarkCanceled is implemented'? Who is calling MarkCancelled? Is that something done from inside the Cancel implementation? Or is that the method used for a container activity to cancel a child activity?
That's correct- this would be called by the developer inside the Cancel implementation (since it requires access to the activity context), and sets the internal state of the executing activity to canceled. The runtime is then made aware of the activity's canceled state, and will behave appropriately in response to various events (such as persistence).