From the comments:
Then how do I avoid this? Just add await keyword?
No, you can't just do that. (And that's why the previously proposed duplicate question was not in fact a duplicate…your scenario is subtly different.) You will need to delay the dispose until the download has completed, but this is complicated by your need to execute two more program statements (at least…it's impossible to know for sure without a good, minimal, complete code example).
I do think you should switch to the awaitable WebClient.DownloadFileTaskAsync()
method, as this will at least simplify the implementation, making it simple to retain the using
statement.
You can address the other part of the problem by capturing the returned Task
object and not awaiting it until after your other program statements have executed:
using (WebClient wc = new WebClient()) {
Task task = wc.DownloadFileTaskAsync(urlUri, outputFile);
SomeMethod1();
SomeMethod2();
await task;
}
In this way, the download can be started, your other two methods called, and then the code will wait for the completion of the download. Only when it's completed will the using
block then be exited, allowing the WebClient
object to be disposed.
Of course, in your current implementation you undoubtedly are handling an appropriate DownloadXXXCompleted
event. If you want, you can continue using the object that way. But IMHO once you have switched over to using await
, it's much better to just put after the await
the code that needs to execute on the completion of the operation. This keeps all of the code relevant to the operation in one place and simplifies the implementation.
If for some reason you can't use await
, then you will have to use some alternate mechanism for delaying the dispose of the WebClient
. Some approaches will allow you to continue to use using
, others will require that you call Dispose()
in the DownloadXXXCompleted
event handler. Without a more complete code example, and a clear explanation for why await
is not suitable, it would not be possible to say for sure what the best alternative would be.
EDIT:
Since you've confirmed that you don't have access to await
in the current code, here are a couple of other options compatible with older code…
One possibility is to just wait in the same thread after starting the operation:
using (WebClient wc = new WebClient()) {
object waitObject = new object();
lock (waitObject)
{
wc.DownloadFileCompleted += (sender, e) =>
{
lock (waitObject) Monitor.Pulse(waitObject);
};
wc.DownloadFileAsync(urlUri, outputFile);
SomeMethod1();
SomeMethod2();
Monitor.Wait(waitObject);
}
}
(Note: one can use any suitable synchronization above, such as ManualResetEvent
, CountdownEvent
, or even Semaphore
and/or "slim" equivalents. I use Monitor
simply due to its simplicity and efficiency, and take as granted readers can adjust to accommodate their preferred means of synchronization. One obvious reason one might prefer something other than Monitor
is that the other types of synchronization techniques won't run the risk of having the DownloadFileCompleted
event handler itself block waiting on the SomeMethod1()
and SomeMethod2()
methods to complete. Whether this is important depends of course on how long those method calls would take as compared to the file download.)
The above will, however, block the current thread. In some cases this may be fine, but most often the operation is being initiated in the UI thread, and that thread should not be blocked for the duration of the operation. In that case, you will want to forego using
altogether and just call Dispose()
from the completion event handler:
WebClient wc = new WebClient();
wc.DownloadFileCompleted += (sender, e) =>
{
wc.Dispose();
};
wc.DownloadFileAsync(urlUri, outputFile);
SomeMethod1();
SomeMethod2();
await
with*TaskAsync
– Burkhartawait
, then there is a problem. – PaunchTask
, the Mjolnir'ed duplicate is less than useful. The OP of the duplicate was fortuitous in that they didn't know they just needed to use async/await with their method. To @JenixGuy, if you're able to useWebClient.DownloadFileTaskAsync()
you can use what's proposed in the duplicate. – OndometerJust add await keyword
if you knew what await did the answer would be obvious to you. Don't add keywords to your code when you are not sure what they do. – Blen