Migrating to async/await is very close to a complete rewrite for our codebase. We're not interested in it because it's such a big undertaking, and if we're forced to we might as well consider options other than .NET. My preference would of course be to leave things that work as-is and get on with the more important aspects of running our business.
https://github.com/dotnet/standard/blob/master/netstandard/r...
I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.
The performance:lines of code ratio you can get with async is quite high. Using ADO.NET you can run mutually exclusive queries in parallel for up-to a 2x speedup (depending on what the queries need to do):
using (var connection1 = ...)
using (var connection2 = ...)
{
var getSomething1Task = GetSomething1Async(connection1, ..., cancellationToken);
var getSomething2Task = GetSomething2Async(connection2, ..., cancellationToken);
await Task.WhenAll(getSomething1Task, getSomething2Task);
// now aggregate results from 1 and 2
}
Unlike in JavaScript, async stuff is optional in C#, so block threads to your heart's content with .Result, it will behave like old sync methods...
Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available.
https://github.com/dotnet/standard/tree/master/netstandard/r...
For things like legacy synchronous or Begin/End async methods, we are more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal.
(I work on .NET at Microsoft).