After reading a recent MSDN Magazine article about the Task scheduler I was hoping (and actually quite excited) that using it would benefit my use of WCF generated proxies.
I was hoping to get some of the following benefits :
- 1) Ability to abort a running WCF operation (I'm not expecting this to stop the operation on the server - I'd just like to be able to signal that 'I don't want the result for this task'. This is especially common in UI where someone repeatedly selects items from a grid that trigger service calls.)
- 2) Ability to start a task at some point other than when it was created - I'm not sure I really need this, I just thought it might be nice to generate a task and not immediately run it. After all I thought that was the whole point of tasks.
- 3) Bindable properties - so I can bind my WCF UI to
IsCompleted
and let the Task class abstract away the operation's internals from my UI. - 4) Ability to abstract away the running of the operation - mocking, blah blah blah, future refactoring etc.
However - I don't seem to get ANY of these benefits.
- 1) There is no abort functionality in Task - which strikes me as really odd.
- 2) The only overload that I could get working with
Task.Factory.FromAsync<>
is the one shown below. This immediately begins execution of the webservice operation (as seen in Fiddler) and doesn't let me start the call later. - 3) Task doesn't implement
INotifyPropertyChanged
so i can't bind it to the UI. - 4) This one is kind of dead in the water given the other 3 benefits aren't happening :-(
Sooo.... Am i just wasting my time trying to get WCF generated proxies working with Tasks -- or am I missing something.
// WCF client
var client = new ShoppingCartClient();
// create task
var t = Task.Factory.FromAsync<GetOrderDetailsMsgOut>(
client.BeginGetOrderDetails(new GetOrderDetailsMsgIn()
{
OrderId = 12345
}, null, null)
, client.EndGetOrderDetails);
t.ContinueWith(x =>
{
var order = x.Result.Order;
// do something with order
});