This would be very nice. It's easy enough to work around, but a built-in approach would be easier to use and probably more efficient.

I know a bunch of people up-voted this and I'd like to know what exactly people expect. The two longest-running methods on the ZipFile class are Save and ExtractAll(), in the various overloads. I could provide async versions of these but wouldn't it be simpler for the caller to just do it themselves, using a BeginInvvoke on an Action delegate?

Action a = zip.Save;
a.BeginInvoke(MyAsynchSaveCompleted, null);

and then

private void MyAsynchSaveCompleted(IAsyncResult ar)
{
Action a = (ar as System.Runtime.Remoting.Messaging.AsyncResult).AsyncDelegate as Action;
try
{
a.EndInvoke(ar);
}
catch(Exception e)
{

// ...

}
}

or even with QueueUserWorkItem() if tracking exceptions isn't important.


There is a school of design that recommends that classes DO NOT provide async interfaces, because it is better to maintain a separation of concerns.

I'm interested in feedback.

Heres my opinion
I would prefer the async operations to be provided in the library - there are plenty of sync and async overloaded methods within the .Net framework.

It does appear to look very simple to do manually - but providing the methods means people get a very easy discoverable way of of how to do it and hopefully some excellent examples.

Some people may see that people should discover how to do it manually and therefore improve their skills. That is a strong argument. But I like things to be easy if the library provides support I will probably try to use it first.

I believe it will be a nice feature add of your library.