Which to use, WebClient.OpenRead, OpenReadAsync or OpenReadTaskAsync












0















I'm trying to understand the differences among WebClient.OpenRead, WebClient.OpenReadAsync and WebClient.OpenReadTaskAsync.



It looks like these have differences regarding blocking a thread, but I don't understand it well.

Could you please explain the differences? It would be great if you could give me some example (examples don't have to be sample code, but would be great if you could provide)










share|improve this question


















  • 1





    It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

    – Hans Passant
    Nov 23 '18 at 9:59
















0















I'm trying to understand the differences among WebClient.OpenRead, WebClient.OpenReadAsync and WebClient.OpenReadTaskAsync.



It looks like these have differences regarding blocking a thread, but I don't understand it well.

Could you please explain the differences? It would be great if you could give me some example (examples don't have to be sample code, but would be great if you could provide)










share|improve this question


















  • 1





    It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

    – Hans Passant
    Nov 23 '18 at 9:59














0












0








0








I'm trying to understand the differences among WebClient.OpenRead, WebClient.OpenReadAsync and WebClient.OpenReadTaskAsync.



It looks like these have differences regarding blocking a thread, but I don't understand it well.

Could you please explain the differences? It would be great if you could give me some example (examples don't have to be sample code, but would be great if you could provide)










share|improve this question














I'm trying to understand the differences among WebClient.OpenRead, WebClient.OpenReadAsync and WebClient.OpenReadTaskAsync.



It looks like these have differences regarding blocking a thread, but I don't understand it well.

Could you please explain the differences? It would be great if you could give me some example (examples don't have to be sample code, but would be great if you could provide)







c# webclient






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 23 '18 at 8:47









KojiKoji

227




227








  • 1





    It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

    – Hans Passant
    Nov 23 '18 at 9:59














  • 1





    It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

    – Hans Passant
    Nov 23 '18 at 9:59








1




1





It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

– Hans Passant
Nov 23 '18 at 9:59





It can take a while to connect to the web server, OpenRead() may hang your user interface for a while. So they provided OpenReadAsync() as an alternative. But it is not so easy to use correctly. In .NET 4.5 they added support for async/await. That made OpenReadTaskAsync() useful, now it is easier to use since you can simply await the method.

– Hans Passant
Nov 23 '18 at 9:59












2 Answers
2






active

oldest

votes


















1














As you said, the difference is in thread blocking behavior. First one (OpenRead()) is thread blocking operation, other two - not. For example, let assume, that your network latency to reach google.com is 300ms. When you do var stream = webClient.OpenRead(@"https://www.google.com"); your application is "paused" for this 300ms, so code next to this line is not executed until your webClient return a stream to stream variable. This is calling Thread blocking.



When you do this in UI-thread (in example: in a button click handler) - your application become freezing and not responding to user actions. This is bad user experience, so never-ever call a thread blocking stuff in your UI. Here is example for console application:



var address = @"https://www.google.com/";

Console.WriteLine($"Opening stream from {address}");
using (var stream = webClient.OpenRead(address)) // this will block for 300ms
{
Console.WriteLine("Stream is open!");
// some other code
}


Second method (OpenReadAsync()) is asynchronous and return nothing immediately after a call, so your thread is not blocked. After awhile (300ms) OpenReadCompleted event will be raised by your webClient and all attached listeners will handle opened stream one-by-one. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
_client.OpenReadCompleted += OpenReadCompletedHandler;
}

private void ButtonClickHandler(object sender, EventArgs e)
{
_client.OpenReadAsync(@"https://www.google.com/");
}

private void OpenReadCompletedHandler(object sender, OpenReadCompletedEventArgs e)
{
// this event will be raiesed 300ms after 'Button' click
var stream = e.Result; // <- here is your stream
// some other code
}
}


The last one (OpenReadTaskAsync()) is all about TPL (Task Parallel Library) and async/await keywords. It runs all stuff in a Task which is returned by this method. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
}

private async void ButtonClickHandler(object sender, EventArgs e)
{
// after 'await' keyword, execution will be returned from this method immediately
// meanwhile, actual acquiring of 'stream' is running in a background thread
using (var stream = await _client.OpenReadTaskAsync(@"https://www.google.com/"))
{
// after 300ms, this code will be continued in UI thread
// result will be automaticly unpacked to 'stream' variable

// some other code
}
}
}


Hope this helps.






share|improve this answer
























  • This is a great answer. Thank you very much

    – Koji
    Nov 25 '18 at 23:22



















1














I'd suggest WebClient is more or less obsolete now, HttpClient is more appropriate for anything targeting .NET framework 4.5+ or .NET core. Just watch out that the latter does not automatically throw exceptions on HTTP error codes (400+).






share|improve this answer
























  • this should be a comment

    – vasily.sib
    Nov 23 '18 at 9:03












Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53443278%2fwhich-to-use-webclient-openread-openreadasync-or-openreadtaskasync%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














As you said, the difference is in thread blocking behavior. First one (OpenRead()) is thread blocking operation, other two - not. For example, let assume, that your network latency to reach google.com is 300ms. When you do var stream = webClient.OpenRead(@"https://www.google.com"); your application is "paused" for this 300ms, so code next to this line is not executed until your webClient return a stream to stream variable. This is calling Thread blocking.



When you do this in UI-thread (in example: in a button click handler) - your application become freezing and not responding to user actions. This is bad user experience, so never-ever call a thread blocking stuff in your UI. Here is example for console application:



var address = @"https://www.google.com/";

Console.WriteLine($"Opening stream from {address}");
using (var stream = webClient.OpenRead(address)) // this will block for 300ms
{
Console.WriteLine("Stream is open!");
// some other code
}


Second method (OpenReadAsync()) is asynchronous and return nothing immediately after a call, so your thread is not blocked. After awhile (300ms) OpenReadCompleted event will be raised by your webClient and all attached listeners will handle opened stream one-by-one. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
_client.OpenReadCompleted += OpenReadCompletedHandler;
}

private void ButtonClickHandler(object sender, EventArgs e)
{
_client.OpenReadAsync(@"https://www.google.com/");
}

private void OpenReadCompletedHandler(object sender, OpenReadCompletedEventArgs e)
{
// this event will be raiesed 300ms after 'Button' click
var stream = e.Result; // <- here is your stream
// some other code
}
}


The last one (OpenReadTaskAsync()) is all about TPL (Task Parallel Library) and async/await keywords. It runs all stuff in a Task which is returned by this method. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
}

private async void ButtonClickHandler(object sender, EventArgs e)
{
// after 'await' keyword, execution will be returned from this method immediately
// meanwhile, actual acquiring of 'stream' is running in a background thread
using (var stream = await _client.OpenReadTaskAsync(@"https://www.google.com/"))
{
// after 300ms, this code will be continued in UI thread
// result will be automaticly unpacked to 'stream' variable

// some other code
}
}
}


Hope this helps.






share|improve this answer
























  • This is a great answer. Thank you very much

    – Koji
    Nov 25 '18 at 23:22
















1














As you said, the difference is in thread blocking behavior. First one (OpenRead()) is thread blocking operation, other two - not. For example, let assume, that your network latency to reach google.com is 300ms. When you do var stream = webClient.OpenRead(@"https://www.google.com"); your application is "paused" for this 300ms, so code next to this line is not executed until your webClient return a stream to stream variable. This is calling Thread blocking.



When you do this in UI-thread (in example: in a button click handler) - your application become freezing and not responding to user actions. This is bad user experience, so never-ever call a thread blocking stuff in your UI. Here is example for console application:



var address = @"https://www.google.com/";

Console.WriteLine($"Opening stream from {address}");
using (var stream = webClient.OpenRead(address)) // this will block for 300ms
{
Console.WriteLine("Stream is open!");
// some other code
}


Second method (OpenReadAsync()) is asynchronous and return nothing immediately after a call, so your thread is not blocked. After awhile (300ms) OpenReadCompleted event will be raised by your webClient and all attached listeners will handle opened stream one-by-one. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
_client.OpenReadCompleted += OpenReadCompletedHandler;
}

private void ButtonClickHandler(object sender, EventArgs e)
{
_client.OpenReadAsync(@"https://www.google.com/");
}

private void OpenReadCompletedHandler(object sender, OpenReadCompletedEventArgs e)
{
// this event will be raiesed 300ms after 'Button' click
var stream = e.Result; // <- here is your stream
// some other code
}
}


The last one (OpenReadTaskAsync()) is all about TPL (Task Parallel Library) and async/await keywords. It runs all stuff in a Task which is returned by this method. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
}

private async void ButtonClickHandler(object sender, EventArgs e)
{
// after 'await' keyword, execution will be returned from this method immediately
// meanwhile, actual acquiring of 'stream' is running in a background thread
using (var stream = await _client.OpenReadTaskAsync(@"https://www.google.com/"))
{
// after 300ms, this code will be continued in UI thread
// result will be automaticly unpacked to 'stream' variable

// some other code
}
}
}


Hope this helps.






share|improve this answer
























  • This is a great answer. Thank you very much

    – Koji
    Nov 25 '18 at 23:22














1












1








1







As you said, the difference is in thread blocking behavior. First one (OpenRead()) is thread blocking operation, other two - not. For example, let assume, that your network latency to reach google.com is 300ms. When you do var stream = webClient.OpenRead(@"https://www.google.com"); your application is "paused" for this 300ms, so code next to this line is not executed until your webClient return a stream to stream variable. This is calling Thread blocking.



When you do this in UI-thread (in example: in a button click handler) - your application become freezing and not responding to user actions. This is bad user experience, so never-ever call a thread blocking stuff in your UI. Here is example for console application:



var address = @"https://www.google.com/";

Console.WriteLine($"Opening stream from {address}");
using (var stream = webClient.OpenRead(address)) // this will block for 300ms
{
Console.WriteLine("Stream is open!");
// some other code
}


Second method (OpenReadAsync()) is asynchronous and return nothing immediately after a call, so your thread is not blocked. After awhile (300ms) OpenReadCompleted event will be raised by your webClient and all attached listeners will handle opened stream one-by-one. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
_client.OpenReadCompleted += OpenReadCompletedHandler;
}

private void ButtonClickHandler(object sender, EventArgs e)
{
_client.OpenReadAsync(@"https://www.google.com/");
}

private void OpenReadCompletedHandler(object sender, OpenReadCompletedEventArgs e)
{
// this event will be raiesed 300ms after 'Button' click
var stream = e.Result; // <- here is your stream
// some other code
}
}


The last one (OpenReadTaskAsync()) is all about TPL (Task Parallel Library) and async/await keywords. It runs all stuff in a Task which is returned by this method. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
}

private async void ButtonClickHandler(object sender, EventArgs e)
{
// after 'await' keyword, execution will be returned from this method immediately
// meanwhile, actual acquiring of 'stream' is running in a background thread
using (var stream = await _client.OpenReadTaskAsync(@"https://www.google.com/"))
{
// after 300ms, this code will be continued in UI thread
// result will be automaticly unpacked to 'stream' variable

// some other code
}
}
}


Hope this helps.






share|improve this answer













As you said, the difference is in thread blocking behavior. First one (OpenRead()) is thread blocking operation, other two - not. For example, let assume, that your network latency to reach google.com is 300ms. When you do var stream = webClient.OpenRead(@"https://www.google.com"); your application is "paused" for this 300ms, so code next to this line is not executed until your webClient return a stream to stream variable. This is calling Thread blocking.



When you do this in UI-thread (in example: in a button click handler) - your application become freezing and not responding to user actions. This is bad user experience, so never-ever call a thread blocking stuff in your UI. Here is example for console application:



var address = @"https://www.google.com/";

Console.WriteLine($"Opening stream from {address}");
using (var stream = webClient.OpenRead(address)) // this will block for 300ms
{
Console.WriteLine("Stream is open!");
// some other code
}


Second method (OpenReadAsync()) is asynchronous and return nothing immediately after a call, so your thread is not blocked. After awhile (300ms) OpenReadCompleted event will be raised by your webClient and all attached listeners will handle opened stream one-by-one. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
_client.OpenReadCompleted += OpenReadCompletedHandler;
}

private void ButtonClickHandler(object sender, EventArgs e)
{
_client.OpenReadAsync(@"https://www.google.com/");
}

private void OpenReadCompletedHandler(object sender, OpenReadCompletedEventArgs e)
{
// this event will be raiesed 300ms after 'Button' click
var stream = e.Result; // <- here is your stream
// some other code
}
}


The last one (OpenReadTaskAsync()) is all about TPL (Task Parallel Library) and async/await keywords. It runs all stuff in a Task which is returned by this method. Here is an example:



public partial class MainForm : Form
{
private WebClient _client = new WebClient();

public MainForm()
{
InitializeComponents();
}

private async void ButtonClickHandler(object sender, EventArgs e)
{
// after 'await' keyword, execution will be returned from this method immediately
// meanwhile, actual acquiring of 'stream' is running in a background thread
using (var stream = await _client.OpenReadTaskAsync(@"https://www.google.com/"))
{
// after 300ms, this code will be continued in UI thread
// result will be automaticly unpacked to 'stream' variable

// some other code
}
}
}


Hope this helps.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 23 '18 at 9:57









vasily.sibvasily.sib

2,26021122




2,26021122













  • This is a great answer. Thank you very much

    – Koji
    Nov 25 '18 at 23:22



















  • This is a great answer. Thank you very much

    – Koji
    Nov 25 '18 at 23:22

















This is a great answer. Thank you very much

– Koji
Nov 25 '18 at 23:22





This is a great answer. Thank you very much

– Koji
Nov 25 '18 at 23:22













1














I'd suggest WebClient is more or less obsolete now, HttpClient is more appropriate for anything targeting .NET framework 4.5+ or .NET core. Just watch out that the latter does not automatically throw exceptions on HTTP error codes (400+).






share|improve this answer
























  • this should be a comment

    – vasily.sib
    Nov 23 '18 at 9:03
















1














I'd suggest WebClient is more or less obsolete now, HttpClient is more appropriate for anything targeting .NET framework 4.5+ or .NET core. Just watch out that the latter does not automatically throw exceptions on HTTP error codes (400+).






share|improve this answer
























  • this should be a comment

    – vasily.sib
    Nov 23 '18 at 9:03














1












1








1







I'd suggest WebClient is more or less obsolete now, HttpClient is more appropriate for anything targeting .NET framework 4.5+ or .NET core. Just watch out that the latter does not automatically throw exceptions on HTTP error codes (400+).






share|improve this answer













I'd suggest WebClient is more or less obsolete now, HttpClient is more appropriate for anything targeting .NET framework 4.5+ or .NET core. Just watch out that the latter does not automatically throw exceptions on HTTP error codes (400+).







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 23 '18 at 8:54









Dylan NicholsonDylan Nicholson

940517




940517













  • this should be a comment

    – vasily.sib
    Nov 23 '18 at 9:03



















  • this should be a comment

    – vasily.sib
    Nov 23 '18 at 9:03

















this should be a comment

– vasily.sib
Nov 23 '18 at 9:03





this should be a comment

– vasily.sib
Nov 23 '18 at 9:03


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53443278%2fwhich-to-use-webclient-openread-openreadasync-or-openreadtaskasync%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

Origin of the phrase “under your belt”?