You're absolutely right. I tried doing it before but at the time it increase the font on things that I didn't want increased and it just looked odd. Will try to fix that. Thanks for the suggestion!
Something I did in a project when needing a resource loaded within a constructor was to build something that let me lazily load the data within an asynchronous context and await when I need it. It was just a small class built on top of Lazy that I called AsyncLazy. I can still pass in my interface that does the asynchronous call but stuff it inside of AsyncLazy and whenever I need that data I can just do (await _settingsLazy).; Plus, in my opinion, I like the way it reads. It tells whoever is reading that piece of code that the data is lazily loaded, cached after the first call, and is done within an asynchronous context.
Agreed. I'd always wondered how to cancel the backend threads once the client canceled the request. Being able to pass the CancellationToken thru the endpoint answered that!
About the last case, when you need to resolve service from DI, there is an article at msdn 'Dependency injection guidelines' with anti-pattern examples where is shown how you can deadlock your thread with an async factory.
Hi Nick, can you explain to me, why should I write "return await new ValueTask(numberToAdd*2);", if I could also write "return numberToAdd*2;" directly. To explain more, we are in an asyc method, so return a value directly is automatically wrapped in a Task (or in this case a ValueTask). So what is the benefit of this additional await?
I’m wondering why it's should be preferred since await should be called where result(or exception) is needed. I don’t use async/await for arrow(wrapper) function which is only prepares input parameters. And also use ContinueWith when need to re-cast result without awaiting public Task GiveMeInt() => Task.FromResult(1L).ContinueWith(task => (int)task.Result, TaskContinuationOptions.ExecuteSynchronously); Await is very optimized in core, but it’s much heavier in full framework.
I actually intentionally left ConfigureAwait and .GetAwaiter().GetResult() because I will be covering them in a dedicated video, since it's just a big topic.
RE: "Don't sync over async in constructors" - do you have a clean solution for setting up this initialization pattern when using the Microsoft.Extensions.DependencyInjection namespace (IServiceCollection, AddScoped, AddTransient, etc.) for DI?
async Task is dangerous if it's an event handler, basically the Task object will not be assigned and not GC-ed, thus catching exceptions will not work. async void is the way to go when used in event handlers or expect to not GC.
20:46 How do you register a method in DI? I'm probably not searching about the topic properly cause I can't find information about that and I've never done it. Thank you for the video btw, I am really interested in improving my understanding of all the scenarios around async/await and love videos you make about that.
Love the information shared ! Thank you Nick. Learned a lot from the "Always pass the CancellationToken" and the "Don't sync over async in constructors" !
Hi Nick, thank you for your hard work and knowledge sharing here. It would be great if you elaborate about best practices on error handling. It is one on the wide and most useful topics. There are a lot of videos and resources on the internet, but still some of the ideas behind them are not clear for me. Thanks.
Another confusing topic you should have addressed is the .ConfigureAwait(Boolean) method on Task. Recent DotNetAnalyzers will prompt you to call this method on every awaited task by default. It's not always clear to people whether they can ignore that rule.
Well, for .NET Core you don't need to use it anymore, unless you're writing a library, because Core itself is not using SynchronizationContext anymore.
10:54 ContinueWith is used in scenarios such as this: var task1 = service.GetValueAsync(id1).ContinueWith(...); var task2 = service.GetValueAsync(id2).ContinueWith(...); Task.WhenAll(task1, task2);
Nick Chapsas, in your first example, could you confirm whether awaiting would actually result in the application closing. As the task would pass back control to the main thread and just exit?
The part at 5:53 is very confusing to me. Why is wrapping the code from SomeBackgroundThingAsync in a try-catch which re-throws, magically making Task.Run aware that an exception has been thrown ? When you say at 5:26 "there is a way to change this, so it throws an UnobservedTaskException", have you done this on the side without showing it between your run at 5:12 and 5:53 ? I tried in a sandbox to simply switch between try-catch and not try-catch, but the result is the same : Task.Run wil fire-and-forget.
... is supported starting with C# 7.0, good tutorial. A good video tutorial will be about your words: " in the dot net scenario there is no way that you cannot await a call ".Thank's for sharing ...
It's not 'really' an async constructor but yeah it's a neat way to handle it :D To be honest, though you would want to avoid this sort of stuff anyway just like Nick said.
hi Nick, suppose i have a workflow with async method calls all the way to the repository, is it a good option to use "Task.FromResult" when i have one method which has no awaitable calls to force it async? or is it a better option to make the method simply syncronous?
The problem I see with the last example, is that static methods are a pain to mock in unit tests. Injecting ConnectionFactory and then using it in specific methods to get MyConnection is probably a better approach? Unless the Connection has to be shared between methods, but it'd mean we need atomicity. Does it make sense to have multiple methods in such case?
There is one usecase where you can kind of not await everything... and that is technical debt. I was facing quite a few cases, where a call just had too many references to be refactored at once. For such cases I used the shown methods for getting the Task results. But I totally agree, in theory even that could be awaited. Its just a matter of priortity.
Thank you for this video! Question: ist the cancellation token global for the whole application? Imagine having a windows service that just got the „shutdown“ command! Wo alle cancellation tokens fire?
Is it really true that SomeBackgroundThingAsync() is actually a background thing? I'd say it's synchronous until it hits an await and then it depends on the current sync context or task scheduler where the continuation carries on.
@@patrikbak8161 in the case of task.run it is registered in and running on the task pool. But with the void the code gets executed immediately up to an await, but after that... I know it will return to the controller and continue the controllers' path. But that function... It probably gets cleaned up by the GC. It would be the same as if you created a task 'dostuff' in a non async function. And in 'dostuff' yielded immediately. Unless you do something with the returned task, 'dostuff' will never continue it's code path beyond the yield.
Nick, can you please explain this to me. @ the 11:19 mark, you are awaiting the number from an async call. Won't the next line of code run and fail if the await call takes a while?
9:10 Well, no. If you're implementing a foreign Interface and that doesn't support async methods, and you need to await async methods inside sync methods of that Interface, there's no other way but to force synchronisation.
I have never used a .NET library in the past 5 years that either isn’t purely async or doesn’t over both a sync and async alternative for its implementation. I am happy to take a look at an example and offer an alternative though
Your video is good. But I want to add to the second point which is about `async void`. IMO it really depends on what you are doing and what is the limitation. More specifically, if you are working with APIs that are not thread-safe, and thus you can't use `Task.Run`, then using `async void` is fine, since `await async` without using `Task.Run` runs in the main thread (which is why the exception in the example crashed the whole process). I guess this happens more likely when working with game engines whose APIs are most likely not thread-safe.
Awesome tutorial Nick. One example of something you cannot make async (I haven't been able to). Is event calls on WinForms and WPF. Take the following Load event on a Form or WPF Window. public async void Load() I can do however if I try public async Task Load() it won't compile. Interested to know your work around to make these async. Custom events I can do, as I declare the delegate, but built in ones are tricky.
As painful as it can be, I've definitely found situations where using the async keyword is not realistically possible. In a legacy application this can mean a huge change across a platform. Or for example a legacy 3rd party plugin that has some kind of hooks that don't support async for example But yeah... If you're writing a new code base just async all the things and thank yourself later
In VB6 we were told not to use DoEvents because it was bad practice. Now we are told to do it in an even more complicated way in C#/VB.NET, using await and async, a way that doesnt solve any of the reasons we were told not to use DoEvents back then and also has a more limited utility (its all or nothing with async, doevents is any time you want) In VB6 we were also told not to use OnError because it was bad practice. Now we are told to use exceptions, something less capable than OnError (see the distinction between Resume and Resume Next.) Spaghetti in the form of objects is still spaghetti.
Thanks for video. I have a question about a scenario I need to code. I have a process that will send a request file via SFTP and then I will need to wait for a response file to be created on the ftp server before I download and continue my processing. The response file could appear within 1min to 60mins. If I await this process, is there a way that I can say, give up after 60 mins?
Making Task F() { using var g = G(); return H(g); } instead of async Task F() { using var g = G(); return await H(g); } is a straight way to get a disposed object accessed
In that specific case, the async/await must be used or pass a delegate to G() inside the task (or call the G() directly in the task). Always is better use the using keyword inside the task. I think the async/await overhead can become significant. However I return task if and only if certain 'rules' are met: * The method that returns the task has the same type of returned task or is a task without result. * The method that returns the task only executes that statement. * The method that returns the task executes that statement at the end and is the only asynchronous call one but, the parameters for this task must not be invalidable (collectable or disposable or mutable outside the task) in the lifetime of the method execution, that includes delegates or tasks (which should be awaited inside the returned task) as parameters. * The method that returns the task must uniquely choose from a finite set of tasks of the same type which one to do based on runtime conditions. Any violation to this 'rules' implicates use async/await.
I think the possibility of a deadlock is much more dangerous than wasting one more thread. Deadlocks are damn hard to spot and debug. Threads are hopefully quite cheap to create (and you can always revert them back if your performance really suffer from it)
Actually in the async void is bad example it is not the Task.Run that causes the process not to die but changing the return type to Task and what that does to the method behind the scenes.
I agree about not using continue with on task but What about about await a task and then using "on faulted " to it, like suppose if a method fails we want to log/send email to ...is that ok?
Hey, I'm using var because I think that my variable declaration name and value assignment should be more than enough to indicate what the type is. The type itself isn't important to me. I can clearly see what it is from the code without explicitly stating it.
@@nickchapsasI had written a game for Xbox live indie games back in 2010 before async/await with c# and xna, and that was probably around the time I also stopped working professionally with c#. After about 10 years I wanted to get back into .net and c# and thought I should port my game to monogame, and uwp to make it work on both windows and newer Xboxes. That's where I had to figure out this new to me async/await. I struggled the most with this one aspect, everyone telling me to avoid async void, and not knowing a better way to integrate async apis into a framework that doesn't support it, specifically update/draw functions from the monogame/xna. Anyways, it would be great if you made a video about that kind of real world integration issue. In any case, I enjoy your content and your knowledge. Keep up the good work.
Hmmm I was taught, by MS that you should not always await every method that returns a task because that's a ton of overhead. If you are not doing something with the task return value there is no need to await. This creates state machines which adds not only CPU cycles but also the memory your app uses. Please explain why you think every task method should be awaited. Thanks!
I may add, that RUN TASK, thing, It is to wrap an otherwise NOT await-able method, for UWP and Windows Sdk App. (WPF programmer, don't know UWP, will be confused.) Example, Windows Sdk App, in side a converter -> will crash, if you copy a WPF converter and try to use on "IT": you need to do this: try { Task.Run(async () => { var stream = await file.OpenReadAsync(); dispatcher.TryEnqueue(async () => await BI.SetSourceAsync(stream)); }); return BI; } ___________ in other words: If you have a BIG method coded with WPF, do not want to recode it for UWP/WAP, That, run-task thing, is very useful. Another Example, with WPF, fetch SQL return from local database, it will wait and blocked, unit it is COMPLETED. Copy that block of code to UWP, it may not work, or crash. Because? the method will return immediately, before the result is completed. FIX? -> that run-task await thing.
I liked the explanation for the cancellation token and AsyncInConstructors a lot. I didn't exactly know the reason for the tokens to be there, but it makes a lot of sense that a controller just continues to do what it was asked for. I'll probably take the static creation method, too. Quite a nice design.
Great Video, Short question do you know if they fixed the problem where cancelation tokens don't trigger in IIS? Cause it still a problem for me at least with the Controllers token in the API Thanks
hey Nick, thanks for all those helpful videos. I have a question, what the name of the extension that displays the inline argument or parameters hint your code?
Just a note with the last one. Changing it into a factory makes DI way more complicated. An alternate solution that works fine is to offload your async construction calls into an async Initialize method. In the constructor, call your Initialize method and assign its resulting task to an instance variable. Then in your async methods that depend on the initialization to be completed, "await _initializationTask;" at the top. No need for factory, still works great with DI, and you can call async stuff safely from the constructor.
@@nickchapsas You don't. You await the task that you've stored in the instance variable from the start of any methods in that class that are dependent on it, by which time it would have likely completed anyway.
@@nickchapsas I think TH-cam is deleting my comments because of a pastebin link, so just in case, here's a pastebin id for an example: "Dask3TsG". It's still deterministic, just asynchronous-- the outcome is the same each time (deterministic), so long as you have a call to await the initialization task. An example use would be if you need to add a client certificate to an HttpClientHandler at construction, but need to fetch the certificate asynchronously.
@@lightandtheheat I really don't like this. If this thing is needed in multiple methods then you're literring every method with a state machine and an awaitable context that could be completed. You're wasting both memory and time and you're leaking a class level concern on a method that shouldn't know about it.
I don't think that exceptions in async void desktop app handlers can cause the app to crash so that usecase would be valid. That being said, I don't have enough experience with desktop apps so I am not aware of any alternatives
Event handlers are mentioned by Microsoft explicitely as being an exception to the "avoid async void" rule, so feel free to use 'async void' for those.
Just as the second Nick said - this is one of the reasons (if not the only one) you can even use void as return type for async functions. Because of event handlers.
In first case it is terminated because still you are running in the main thread. Async Await is not by default running in sub threads / tasks. Here my async await video : th-cam.com/video/I4cnX_odC1M/w-d-xo.html . continuewith is good if you are not awaiting the task result.
How about using using(idisposible) on async tasks. And on your last solution: after i've done what u say, now i cant use ioc container to create instence of SomeService. What am i supposed to do now? I wanna inject SomeService to my controller via dependency resolver.
They added await using in c# 8. As for async in the constructor David Fowler recommends doing your async initialization in IHostedService before the app starts, for lazy initialization you can write a filter or middleware that will run your init logic before the request then just inject things a usual.
@@FilipCordas what u r saying sounds really good, but first we need to understand the concept. First we must understand what happens if we don't do it, what does it couse bla bla bla.
Realy like ur videos about .net. Are you going make video about delegates in c#? More about their usage, cause theory is quiet simple, but there very few good examples of their usage.
.NET Core doesn’t have a sync context so it doesn’t matter, but in that specific example it wouldn’t matter even if there was one because the task has completed and we can get the result as a property
If the code is guaranteed to only run in a .NET Core app, it can be omitted as .NET Core does not have a SynchronizationContext. However, if the code is built as a library (maybe it's compiled under .NET Standard) and that library might be used by an app that is running on .NET Framework, it should be added since .NET Framework does have a SynchronizationContext.
@@michielarkema But in the video he writes new Exception(message: "Message..") in lower case and inside the parentheses, which is what my comment was about.
Hi, Nick! Thanks for the video. Can I ask you a probably dumb question? You see, I have this problem with async/await in WPF if I try to implement MVVM pattern. Turns out, in a view model properties can't be async. I looked it up on stackoverflow, but their solution is a bit too complex for me so for now I simply either go synchronous or don't do MVVM. But I'm pretty sure there must be some simple and correct way of doing this, which I don't know because I'm self-taught and lazy. After watching your video I thought, this is the person who can help me or at least point in the right direction. Thanks in advance.
I do this by having a base ViewModel class that implements the INotifyPropertyChanged, and that gets an Action injected that it can call to actually notify. In unit tests, injected Action just runs (whatever....), in real code, the injected Action conditionally invokes (CheckAccess/BeginInvoke) on the Dispatcher (of the window that did the dependency injection at startup). No async/await, though. Needs to use Tasks. Any better ideas to actually go async, appreciated.
@@jessicafrankston7155 You don't have to implement INPC manually in 2022; It's more error-prone and results in massive boilerplate blocks. Use the CommunityToolkit and inherit from ObservableObject. It also contains source generators accompanying the [ObservableProperty] attribute.
The cancellation token should be used with care. Canceling a save operaton half-way through could leave your database in a undesirable state (half-saved objects).
Ideally all your db operations in a since call should be atomic. Breaking them down to multiple calls or having them be non-transactional is dangerous no matter whether you use a cancellation token or not
Disagree on ContinueWith. Where I have further processing on a Task, I find it convenient to be able to do that in a temporary scope so as to not introduce temporary variables into the outer scope (like you've done). Like chaining promises in javascript, it is very clean and simple. I don't see any convincing arguments here. To me, you've made the code worse by introducing a new variable (finalNumber). If you're going to say "Don't do something", you're going to need to say why.
Yeah I forgot to mention that if you don't want that process to be cancellable then you shouldn't be passing the token. Something like an asynchronous email sending for example.
Thank's for the mention :) also a very needed video on youtube, well done. One thing I could reccomend is to increase the font on Rider's menu's
You're absolutely right. I tried doing it before but at the time it increase the font on things that I didn't want increased and it just looked odd. Will try to fix that. Thanks for the suggestion!
Something I did in a project when needing a resource loaded within a constructor was to build something that let me lazily load the data within an asynchronous context and await when I need it. It was just a small class built on top of Lazy that I called AsyncLazy. I can still pass in my interface that does the asynchronous call but stuff it inside of AsyncLazy and whenever I need that data I can just do (await _settingsLazy).;
Plus, in my opinion, I like the way it reads. It tells whoever is reading that piece of code that the data is lazily loaded, cached after the first call, and is done within an asynchronous context.
Dude the cancelation token at endpoint lvl was awesome.
Agreed. I'd always wondered how to cancel the backend threads once the client canceled the request. Being able to pass the CancellationToken thru the endpoint answered that!
Really appreciate the timestamps in the description. Keep up the good work
Chapters in the timeline too!
About the last case, when you need to resolve service from DI, there is an article at msdn 'Dependency injection guidelines' with anti-pattern examples where is shown how you can deadlock your thread with an async factory.
I think simpler thing to do is to initialize the dependency and then inject it.
Hi Nick, can you explain to me, why should I write "return await new ValueTask(numberToAdd*2);", if I could also write "return numberToAdd*2;" directly. To explain more, we are in an asyc method, so return a value directly is automatically wrapped in a Task (or in this case a ValueTask). So what is the benefit of this additional await?
"You should avoid async void". Well that's where the word "avoid" from.
))))
"You should make async void... Well void and not use it."
I’m wondering why it's should be preferred since await should be called where result(or exception) is needed. I don’t use async/await for arrow(wrapper) function which is only prepares input parameters. And also use ContinueWith when need to re-cast result without awaiting public Task GiveMeInt() => Task.FromResult(1L).ContinueWith(task => (int)task.Result, TaskContinuationOptions.ExecuteSynchronously);
Await is very optimized in core, but it’s much heavier in full framework.
Great content Nick. You should have also shared some insight on 'ConfigureAwait' 😉
I actually intentionally left ConfigureAwait and .GetAwaiter().GetResult() because I will be covering them in a dedicated video, since it's just a big topic.
@@nickchapsas Will wait for that videos too!!
@@nickchapsas seems like you haven't uploaded that video yet. Please do so, will be glad to check
RE: "Don't sync over async in constructors" - do you have a clean solution for setting up this initialization pattern when using the Microsoft.Extensions.DependencyInjection namespace (IServiceCollection, AddScoped, AddTransient, etc.) for DI?
async Task is dangerous if it's an event handler, basically the Task object will not be assigned and not GC-ed, thus catching exceptions will not work. async void is the way to go when used in event handlers or expect to not GC.
7:35 why you awaiting this ValueTask you can just `return new ValueTask(numberToAdd * 2);`
Ah man, I should update my personal project... Thanks alot Nick.
I really liked the way to pass a factory to a constructor that you need to make async. Very enlighting. Thank you Nick!
20:46 How do you register a method in DI? I'm probably not searching about the topic properly cause I can't find information about that and I've never done it. Thank you for the video btw, I am really interested in improving my understanding of all the scenarios around async/await and love videos you make about that.
Love the information shared ! Thank you Nick. Learned a lot from the "Always pass the CancellationToken" and the "Don't sync over async in constructors" !
Hi Nick, thank you for your hard work and knowledge sharing here. It would be great if you elaborate about best practices on error handling. It is one on the wide and most useful topics. There are a lot of videos and resources on the internet, but still some of the ideas behind them are not clear for me. Thanks.
I'm more curious about the async await mistakes I should be making
Another confusing topic you should have addressed is the .ConfigureAwait(Boolean) method on Task. Recent DotNetAnalyzers will prompt you to call this method on every awaited task by default. It's not always clear to people whether they can ignore that rule.
Well, for .NET Core you don't need to use it anymore, unless you're writing a library, because Core itself is not using SynchronizationContext anymore.
@@EvaldasNaujikas *ASP.Net core
10:54 ContinueWith is used in scenarios such as this:
var task1 = service.GetValueAsync(id1).ContinueWith(...);
var task2 = service.GetValueAsync(id2).ContinueWith(...);
Task.WhenAll(task1, task2);
I have never used it that way. I use Task.WhenAll() when I have a variable length of bound tasks to perform.
Thank you for this video, now I know that async/await in our codebase is really messy.
Nick Chapsas, in your first example, could you confirm whether awaiting would actually result in the application closing. As the task would pass back control to the main thread and just exit?
It will completely fall over and stop running
The part at 5:53 is very confusing to me. Why is wrapping the code from SomeBackgroundThingAsync in a try-catch which re-throws, magically making Task.Run aware that an exception has been thrown ?
When you say at 5:26 "there is a way to change this, so it throws an UnobservedTaskException", have you done this on the side without showing it between your run at 5:12 and 5:53 ?
I tried in a sandbox to simply switch between try-catch and not try-catch, but the result is the same : Task.Run wil fire-and-forget.
Task.Run is not aware that an exception has been thrown.
The exception is simply logged in the catch of SomeBackgroundThingAsync.
@nick You are very nice Guy, I am developer some years, but i am learning to much with you about .NET. Tks
... is supported starting with C# 7.0, good tutorial. A good video tutorial will be about your words: " in the dot net scenario there is no way that you cannot await a call ".Thank's for sharing ...
The static async method is really clever, had that problem for years
I had never seen such an elegant way to handle async calls in a constructor... I will surely use that since this day on. Thanks!
It's not 'really' an async constructor but yeah it's a neat way to handle it :D
To be honest, though you would want to avoid this sort of stuff anyway just like Nick said.
hi Nick, suppose i have a workflow with async method calls all the way to the repository, is it a good option to use "Task.FromResult" when i have one method which has no awaitable calls to force it async? or is it a better option to make the method simply syncronous?
The problem I see with the last example, is that static methods are a pain to mock in unit tests. Injecting ConnectionFactory and then using it in specific methods to get MyConnection is probably a better approach? Unless the Connection has to be shared between methods, but it'd mean we need atomicity. Does it make sense to have multiple methods in such case?
Brilliant gotchas picked.
Very concise and understandable demo sequencing.
You are a very good teacher, sir.
Hi Nick,
How do you pass cancellationToken to Task.WhenAll()?
hi Nick,
when use EF Core with action Insert, Update, Delete data, we should pass CancellationToken?
Thank you
How do you cancel a Task where it calls a blocking call from another API which you can't change, that's not designed to be cancellable?
COOL: Enumerable.Empty .. I didn't know
There is one usecase where you can kind of not await everything... and that is technical debt.
I was facing quite a few cases, where a call just had too many references to be refactored at once. For such cases I used the shown methods for getting the Task results. But I totally agree, in theory even that could be awaited. Its just a matter of priortity.
Thank you for this video! Question: ist the cancellation token global for the whole application?
Imagine having a windows service that just got the „shutdown“ command!
Wo alle cancellation tokens fire?
Is it really true that SomeBackgroundThingAsync() is actually a background thing? I'd say it's synchronous until it hits an await and then it depends on the current sync context or task scheduler where the continuation carries on.
It’s actually a background thing yeah, you can get the source and try it yourself
@@nickchapsas It wouldn't be in a console application.
@@patrikbak8161 in the case of task.run it is registered in and running on the task pool. But with the void the code gets executed immediately up to an await, but after that... I know it will return to the controller and continue the controllers' path. But that function... It probably gets cleaned up by the GC.
It would be the same as if you created a task 'dostuff' in a non async function. And in 'dostuff' yielded immediately. Unless you do something with the returned task, 'dostuff' will never continue it's code path beyond the yield.
Nick, can you please explain this to me. @ the 11:19 mark, you are awaiting the number from an async call. Won't the next line of code run and fail if the await call takes a while?
9:10 Well, no. If you're implementing a foreign Interface and that doesn't support async methods, and you need to await async methods inside sync methods of that Interface, there's no other way but to force synchronisation.
I have never used a .NET library in the past 5 years that either isn’t purely async or doesn’t over both a sync and async alternative for its implementation. I am happy to take a look at an example and offer an alternative though
Awesome Nick. Clear and easy to understand. Keep simple. Thanks
Your video is good. But I want to add to the second point which is about `async void`. IMO it really depends on what you are doing and what is the limitation. More specifically, if you are working with APIs that are not thread-safe, and thus you can't use `Task.Run`, then using `async void` is fine, since `await async` without using `Task.Run` runs in the main thread (which is why the exception in the example crashed the whole process).
I guess this happens more likely when working with game engines whose APIs are most likely not thread-safe.
Awesome tutorial Nick. One example of something you cannot make async (I haven't been able to). Is event calls on WinForms and WPF. Take the following Load event on a Form or WPF Window. public async void Load() I can do however if I try public async Task Load() it won't compile. Interested to know your work around to make these async. Custom events I can do, as I declare the delegate, but built in ones are tricky.
Wondering what to do for Property changes in WPF
As painful as it can be, I've definitely found situations where using the async keyword is not realistically possible. In a legacy application this can mean a huge change across a platform. Or for example a legacy 3rd party plugin that has some kind of hooks that don't support async for example
But yeah... If you're writing a new code base just async all the things and thank yourself later
Legacy applications and await async are the worst possible combination really. You really really wanna refactor some stuff but your hands are tied.
In VB6 we were told not to use DoEvents because it was bad practice. Now we are told to do it in an even more complicated way in C#/VB.NET, using await and async, a way that doesnt solve any of the reasons we were told not to use DoEvents back then and also has a more limited utility (its all or nothing with async, doevents is any time you want) In VB6 we were also told not to use OnError because it was bad practice. Now we are told to use exceptions, something less capable than OnError (see the distinction between Resume and Resume Next.) Spaghetti in the form of objects is still spaghetti.
Thanks for video. I have a question about a scenario I need to code. I have a process that will send a request file via SFTP and then I will need to wait for a response file to be created on the ftp server before I download and continue my processing. The response file could appear within 1min to 60mins. If I await this process, is there a way that I can say, give up after 60 mins?
Making
Task F() { using var g = G(); return H(g); }
instead of
async Task F() { using var g = G(); return await H(g); }
is a straight way to get a disposed object accessed
In that specific case, the async/await must be used or pass a delegate to G() inside the task (or call the G() directly in the task). Always is better use the using keyword inside the task.
I think the async/await overhead can become significant. However I return task if and only if certain 'rules' are met:
* The method that returns the task has the same type of returned task or is a task without result.
* The method that returns the task only executes that statement.
* The method that returns the task executes that statement at the end and is the only asynchronous call one but, the parameters for this task must not be invalidable (collectable or disposable or mutable outside the task) in the lifetime of the method execution, that includes delegates or tasks (which should be awaited inside the returned task) as parameters.
* The method that returns the task must uniquely choose from a finite set of tasks of the same type which one to do based on runtime conditions.
Any violation to this 'rules' implicates use async/await.
9:20 how a IValueConverter method could be async?
An excellent video going over Async. Lots of great information here!
I think the possibility of a deadlock is much more dangerous than wasting one more thread. Deadlocks are damn hard to spot and debug. Threads are hopefully quite cheap to create (and you can always revert them back if your performance really suffer from it)
Hey, what is the var:type extension?
at 14:25 you returned Enumerable.Empty() in async method, shouldn't your rather return await Task.FromResult(Enumerable.Empty...) ?
Great video!
if an async operation doesnt return any result, just use fire forget. is it correct?
How can I inject async connection on my controllers contructors? I cant use this static approach on my controllers that extends ControllerBase
You can do that by creating a service, initialising in that new service and then injecting it in the controller
Thank you so much for this video it has been enlightening!!
I really like nick and raw coading's video...
Actually in the async void is bad example it is not the Task.Run that causes the process not to die but changing the return type to Task and what that does to the method behind the scenes.
Very nice indeed, especially the cancellation token demo 👍.
Keep posting more videos about this topic 👏👏
Great stuff...Very useful insights...Thank you.
I agree about not using continue with on task but What about about await a task and then using "on faulted " to it, like suppose if a method fails we want to log/send email to ...is that ok?
Try/catch it
That async task delay in a gamechanger for task cancelation, used to have to loop 😩
Hi Nick, I'd like to ask if you are using var just because you do not want to write the type of the variable or are there any other reason for that?
Hey, I'm using var because I think that my variable declaration name and value assignment should be more than enough to indicate what the type is. The type itself isn't important to me. I can clearly see what it is from the code without explicitly stating it.
@@nickchapsas Oh, okay, thanks! Something new to me.
In a scenario where you override a method that does not have async in the signature, how do you await without an async void?
You can't
@@nickchapsasI had written a game for Xbox live indie games back in 2010 before async/await with c# and xna, and that was probably around the time I also stopped working professionally with c#. After about 10 years I wanted to get back into .net and c# and thought I should port my game to monogame, and uwp to make it work on both windows and newer Xboxes.
That's where I had to figure out this new to me async/await. I struggled the most with this one aspect, everyone telling me to avoid async void, and not knowing a better way to integrate async apis into a framework that doesn't support it, specifically update/draw functions from the monogame/xna.
Anyways, it would be great if you made a video about that kind of real world integration issue.
In any case, I enjoy your content and your knowledge. Keep up the good work.
Does value task still uses the threadpool ?
Hmmm I was taught, by MS that you should not always await every method that returns a task because that's a ton of overhead. If you are not doing something with the task return value there is no need to await. This creates state machines which adds not only CPU cycles but also the memory your app uses.
Please explain why you think every task method should be awaited.
Thanks!
I should add that yes, you should eventually await the the stack and can even mix awaiting and not awaiting in a single call stack.
I may add,
that RUN TASK, thing,
It is to wrap an otherwise NOT await-able method, for UWP and Windows Sdk App. (WPF programmer, don't know UWP, will be confused.)
Example, Windows Sdk App, in side a converter -> will crash, if you copy a WPF converter and try to use on "IT":
you need to do this:
try
{
Task.Run(async () =>
{
var stream = await file.OpenReadAsync();
dispatcher.TryEnqueue(async () => await BI.SetSourceAsync(stream));
});
return BI;
}
___________
in other words:
If you have a BIG method coded with WPF, do not want to recode it for UWP/WAP,
That, run-task thing, is very useful.
Another Example, with WPF, fetch SQL return from local database, it will wait and blocked, unit it is COMPLETED.
Copy that block of code to UWP, it may not work, or crash.
Because? the method will return immediately, before the result is completed.
FIX? -> that run-task await thing.
for fire and forget/return avoid configureAwait(false) will do isn't it ?
This really depends on the sync context of your app. In .NET Core you don't need it.
@@nickchapsas ouhhh okayy thank you nick ! :)
Awesome content. Waiting for more on async await.
I've watched a ton of your videos and after each one I keep saying to myself "how come this guy doesn't have at least 100k subs already?!"
not many people use dotnet
@@jonathandaniel7321 fake news. a lot of corporations do especially in fin tech space.
cause he is a Java guy disguised as C# (based on IDE)
I liked the explanation for the cancellation token and AsyncInConstructors a lot. I didn't exactly know the reason for the tokens to be there, but it makes a lot of sense that a controller just continues to do what it was asked for.
I'll probably take the static creation method, too. Quite a nice design.
Great Video,
Short question do you know if they fixed the problem where cancelation tokens don't trigger in IIS?
Cause it still a problem for me at least with the Controllers token in the API
Thanks
Google bless you!
hey Nick, thanks for all those helpful videos. I have a question, what the name of the extension that displays the inline argument or parameters hint your code?
Heya. It’s not an extension, it’s a built in feature in the idea I am using, called Rider
Look for ReSharper. Visual studio big extention pack from the Rider authors.
Did you check if they also count for F#, or is this just for C#?
Since these are CLR specific, they should stand true for F# as well
Just a note with the last one. Changing it into a factory makes DI way more complicated. An alternate solution that works fine is to offload your async construction calls into an async Initialize method. In the constructor, call your Initialize method and assign its resulting task to an instance variable. Then in your async methods that depend on the initialization to be completed, "await _initializationTask;" at the top. No need for factory, still works great with DI, and you can call async stuff safely from the constructor.
I think I don’t fully get it. How do you asynchronously await from the ctor?
@@nickchapsas You don't. You await the task that you've stored in the instance variable from the start of any methods in that class that are dependent on it, by which time it would have likely completed anyway.
@@lightandtheheat Oh no I would never do that. I like deterministic behaviors in the software I write.
@@nickchapsas I think TH-cam is deleting my comments because of a pastebin link, so just in case, here's a pastebin id for an example: "Dask3TsG". It's still deterministic, just asynchronous-- the outcome is the same each time (deterministic), so long as you have a call to await the initialization task. An example use would be if you need to add a client certificate to an HttpClientHandler at construction, but need to fetch the certificate asynchronously.
@@lightandtheheat I really don't like this. If this thing is needed in multiple methods then you're literring every method with a state machine and an awaitable context that could be completed. You're wasting both memory and time and you're leaking a class level concern on a method that shouldn't know about it.
So what do you do with event handlers in desktop applications that have to be async void?
I don't think that exceptions in async void desktop app handlers can cause the app to crash so that usecase would be valid. That being said, I don't have enough experience with desktop apps so I am not aware of any alternatives
Event handlers are mentioned by Microsoft explicitely as being an exception to the "avoid async void" rule, so feel free to use 'async void' for those.
Just as the second Nick said - this is one of the reasons (if not the only one) you can even use void as return type for async functions. Because of event handlers.
Task.FromResult Nice touch!
In first case it is terminated because still you are running in the main thread. Async Await is not by default running in sub threads / tasks. Here my async await video : th-cam.com/video/I4cnX_odC1M/w-d-xo.html . continuewith is good if you are not awaiting the task result.
How would I use await inside a catch statement in vb.net?
Really Readlly useful !!! Thank you
How about using using(idisposible) on async tasks.
And on your last solution: after i've done what u say, now i cant use ioc container to create instence of SomeService. What am i supposed to do now? I wanna inject SomeService to my controller via dependency resolver.
They added await using in c# 8. As for async in the constructor David Fowler recommends doing your async initialization in IHostedService before the app starts, for lazy initialization you can write a filter or middleware that will run your init logic before the request then just inject things a usual.
@@FilipCordas what u r saying sounds really good, but first we need to understand the concept. First we must understand what happens if we don't do it, what does it couse bla bla bla.
Realy like ur videos about .net. Are you going make video about delegates in c#? More about their usage, cause theory is quiet simple, but there very few good examples of their usage.
Very well done
Amazing! Applying into project right now! 🙏😁
Thank you so much for this. Best practices vids are the best.
Rather than using .Result on the end of your await calls should you not use .ConfigureAwait(false) ??
.NET Core doesn’t have a sync context so it doesn’t matter, but in that specific example it wouldn’t matter even if there was one because the task has completed and we can get the result as a property
If the code is guaranteed to only run in a .NET Core app, it can be omitted as .NET Core does not have a SynchronizationContext. However, if the code is built as a library (maybe it's compiled under .NET Standard) and that library might be used by an app that is running on .NET Framework, it should be added since .NET Framework does have a SynchronizationContext.
What's with the "new Exception(message: "bla.." I had never seen that type of declaration before.
You can throw your own exceptions.
@@michielarkema I know, but I would have written it
new Exception ("Message..")
or
new Exception () { Message: "Message.." };
@@UntakenNick The first one.
@@michielarkema But in the video he writes
new Exception(message: "Message..")
in lower case and inside the parentheses, which is what my comment was about.
@@UntakenNick oh that's just syntax highlighting from the ide.
Which IDE is he using?
Thank you, this is very helpful
Nick didn't really give a reason why once async should always be async. Can someone explain?
Hi, Nick! Thanks for the video. Can I ask you a probably dumb question? You see, I have this problem with async/await in WPF if I try to implement MVVM pattern. Turns out, in a view model properties can't be async. I looked it up on stackoverflow, but their solution is a bit too complex for me so for now I simply either go synchronous or don't do MVVM. But I'm pretty sure there must be some simple and correct way of doing this, which I don't know because I'm self-taught and lazy. After watching your video I thought, this is the person who can help me or at least point in the right direction. Thanks in advance.
I do this by having a base ViewModel class that implements the INotifyPropertyChanged, and that gets an Action injected that it can call to actually notify. In unit tests, injected Action just runs (whatever....), in real code, the injected Action conditionally invokes (CheckAccess/BeginInvoke) on the Dispatcher (of the window that did the dependency injection at startup). No async/await, though. Needs to use Tasks. Any better ideas to actually go async, appreciated.
@@jessicafrankston7155 You don't have to implement INPC manually in 2022; It's more error-prone and results in massive boilerplate blocks. Use the CommunityToolkit and inherit from ObservableObject. It also contains source generators accompanying the [ObservableProperty] attribute.
The cancellation token should be used with care. Canceling a save operaton half-way through could leave your database in a undesirable state (half-saved objects).
Ideally all your db operations in a since call should be atomic. Breaking them down to multiple calls or having them be non-transactional is dangerous no matter whether you use a cancellation token or not
this is what we are waiting for. Thanks!
You could say we have been...awaiting it....dudu tsss...ok I'll see myself out.
catch (TaskCanceledException) when (cancellationToken.IsCancellationRequested)
Thanks Nick..
Disagree on ContinueWith. Where I have further processing on a Task, I find it convenient to be able to do that in a temporary scope so as to not introduce temporary variables into the outer scope (like you've done). Like chaining promises in javascript, it is very clean and simple.
I don't see any convincing arguments here. To me, you've made the code worse by introducing a new variable (finalNumber).
If you're going to say "Don't do something", you're going to need to say why.
Always pass the CancellationToken - while I do agree with this in general , they should be employed tactically.
Yeah I forgot to mention that if you don't want that process to be cancellable then you shouldn't be passing the token. Something like an asynchronous email sending for example.
@@nickchapsas great stuff regardless, keep it coming!
good stuff from 00:01 ;)
Very useful video
What's the IDE he's using?
JetBrains Rider
For the Ante part, this should be that if you get one of your cards STOLEN by a Bat, you have to take it out of your deck.
Looks like I can't use Async with ref params🤔
Had to use tupel