最近のお仕事で、C#の非同期処理の書き方が分からずに、溶岩地帯に自爆していくコードを沢山みるようになったので、ケースとして日常風の記事にしてみました。

どんな風にハマってしまい、どうやって解決するのかが分かると思います。

結論

先に書いておきます。

1. Task.Run()を使ってはいけません
2. Task.Result, Task.Wait()を使ってはいけません
3. Threadクラスを使ってはいけません
4. async-await構文だけを使って書きます
5. async voidにするのは特殊な場合だけです

がんばれー、わかってしまえば難しくない！

補足: もしあなたがJavaScriptで非同期処理を書いた事があるなら、その知識をそのまま生かせます。
JavaScriptではTaskの代わりにPromiseを使いますが、Promiseには上記1,2,3は存在しません。しかし、それで困ることはありませんよね？ （これはとても重要な示唆です）

平和の終焉

以下のような実装を考えます:

// Web APIからデータを取得する
public string FetchData()
{
    // TODO: ここにWeb APIからのデータ取得コードを書く
}

ここからコードを書こうとしている人は既に罠にはまっているわけですが、気が付けないので、そのままここに肉付けをしていくわけです。

Web APIにアクセスするには、今はHttpClientを使いますが、彼らは使い慣れているWebClientを使います:

// Web APIからデータを取得する
public string FetchData()
{
    WebClient wc = new WebClient();
    string body = wc.DownloadString("https://example.com/api/data");
    return body;
}

出来ました。ただ、WebClientのドキュメントを見ると、今から使用するのは推奨しない、代わりにHttpClientを使うように、という事が書かれています。また、レビュアーに指摘されたり、ググったりして見ても、やはりもうWebClientは使うな、と言うような情報が得られます。そこでこれを書き換えようとするわけです。

（なお、今回の題材はWeb APIですが、例えばRedisだとかAzureのサービスとかで提供されるSDKとか、もう大半が非同期処理対応のAPIしか用意されていなかったりするので、Web API固有の話ではないという事に注意して下さい）

Day 1

Sync氏は、WebClientをHttpClientに書き換えていきます。しかし、GetStringがありません。代わりに、GetStringAsyncという似たようなのがあるので、これを使おうとします:

// Web APIからデータを取得する
public string FetchData()
{
    HttpClient hc = new HttpClient();

    // エラー: 型が合わない
    string body = hc.GetStringAsync("https://example.com/api/data");

    return body;
}

GetStringAsyncというのを使ったら、型が合わないというエラーが出ます（幸いなことに？ Sync氏はvarを使わないので、ここでエラーを検出）。よくよく見ると、Task<string>という型です。

ここで彼らの運命は分岐します。どちらも溶岩地帯です。

Day 2 – ピュアなResult

MSDN公式のTaskクラスのドキュメントを読むとサンプルコードがあり、どうやらResultプロパティで結果を取得できるらしい。

（すいません、この記事書いててちょっと頭クラクラしてます… 上のドキュメントは初心者をサイレントに殺しに掛かっているので、見ない方が良いです。リンクは消しました）

// Web APIからデータを取得する
public string FetchData()
{
    HttpClient hc = new HttpClient();

    // Taskは良く分からないけど、Resultプロパティを見れば結果が得られそうだ
    // 型もばっちり一致して、コンパイルが通ったぞ！
    string body = hc.GetStringAsync("https://example.com/api/data").Result;

    return body;
}

起きうる結果について:

• GUIアプリケーション（WinForms, WPF, Xamarinなど）: 何かの拍子にアプリケーションが固まる。原因不明
• サーバーサイド（ASP.NETなど）: 同時接続によるパフォーマンスが悪い、全然伸びない

Day 3 – 分身するResult

GUIアプリケーションを苦労してデバッグしていくと、どうもResultが返ってこないことがあることが分かった。ASP.NETの方は、皆目見当がつかない。そこそこ良いVMを割り当てているのに、.NETって性能悪いの？それともWindows VMのせいなの？ Linuxにすれば良いの？

そうは言っても納期が迫っているので、何とかしなければならない…

そうだ、ワーカースレッドでResult取得するところを分離すれば固まらなく出来るのでは？ 性能上げられるのでは？？ さっきのドキュメント読んだら、Task.Runを使えば簡単にワーカースレッド使えるみたいだし、これで行こう！

// Web APIからデータを取得する
public string FetchData()
{
    HttpClient hc = new HttpClient();

    // Taskって便利だね！ワーカースレッド簡単に使えるんだ
    string body = Task.Run(() =>
        hc.GetStringAsync("https://example.com/api/data").Result).Result;

    return body;
}

起きうる結果について:

• GUIアプリケーション（WinForms, WPF, Xamarinなど）: 何かの拍子にアプリケーションが固まる。原因不明
• サーバーサイド（ASP.NETなど）: 同時接続によるパフォーマンスが悪い、全然伸びない。Day 2より悪化

Day 4 – async-awaitの存在を見出す

もうわかんない、HttpClientとかTaskとか何もわからない… Taskでググるとasync-awaitとか言うやつが出てくるから、これを使えばいいのかな…

// Web APIからデータを取得する
public string FetchData()
{
    HttpClient hc = new HttpClient();

    // async-awaitの書き方本当にわからない...
    // 1日試行錯誤してやっとエラー出なくなった...
    string body = Task.Run(async () =>
        await hc.GetStringAsync("https://example.com/api/data")).Result;

    return body;
}

起きうる結果について:

• GUIアプリケーション（WinForms, WPF, Xamarinなど）: 何かの拍子にアプリケーションが固まる。原因不明
• サーバーサイド（ASP.NETなど）: 同時接続によるパフォーマンスが悪い、全然伸びない。Day 2ぐらい。多分この人はその違いを測定してない…

Day 5 – スレッド手動操作

わかったわかった、Taskなんて使うからダメなんだ。初めからThreadクラスを使えば良かったんだよ。

// Web APIからデータを取得する
public string FetchData()
{
    HttpClient hc = new HttpClient();

    // Taskなんて意味わかんないし、これでいいや。
    // でも何でこんなの使うの？ WebClientでよくね？
    string body;
    Thread thread = new Thread(() =>
        body = hc.GetStringAsync("https://example.com/api/data").Result);
    thread.Start();
    thread.Join();

    return body;
}

起きうる結果について:

• GUIアプリケーション（WinForms, WPF, Xamarinなど）: 一応動作はする。但し、Web APIアクセス中は固まる
• サーバーサイド（ASP.NETなど）: 同時接続によるパフォーマンスが悪い、全然伸びない。Day 2と同じ

わけがわからないよ。どうしてみんなはそんなにHttpClientにこだわるんだい？

Day 6 – 真実

Sync氏「HttpClientだと固まったり性能が上がりません。HttpClientは動作が怪しいので多分バグってます。WebClientを使う方が安全です」

レビュアー「駄目です、HttpClientを使ってください。こう書きます」

// Web APIからデータを取得する
public async Task<string> FetchDataAsync()
{
    var hc = new HttpClient();
    return await hc.GetStringAsync("https://example.com/api/data");
}

レビュアー「非同期処理を行うメソッドは、必ずTaskクラスを返すようにします。また、実際にはHttpClientはstaticで保持る必要があります。とりあえずこんな感じで他のも全部直してください」

Sync氏「え、でもこれだと、メソッド名も戻り値も変わっちゃってるので、呼び出し元にも修正が入ってしまいます」

レビュアー「呼び出し元も直してください。他にうまくやる方法はありません。実際には、メソッド名は直さなくても良いですが、直しておいた方が後々困らないです」

Sync氏「(絶望…)」

（補足: 文字通りです。大げさな話ではなく、他に方法はありません。試行錯誤は時間の無駄になります。警告しましたよ？）

Day 7 – GUIの真実

Sync氏は、必死にGUIのコードを直していた。

// コンストラクタ
public FoolishForm()
{
    // エラー: 型が合わない
    button.Click += this.Button_ClickAsync;
}

// ボタンがクリックされたら、データを取得して反映
public async Task Button_ClickAsync(object sender, EventArgs e)
{
    // データを得る
    var data = await this.FetchDataAsync();
    // テキストボックスに反映
    this.textBox.Text = data;
}

良い所まで来ていたが、Button_ClickAsyncメソッドをイベントハンドラとして登録するところで、型のエラーが発生して悩んでいた。

数時間後…

Sync氏「イベントハンドラの部分はどう書けばいいんですか？型が合わないと言われてしまいます」

レビュアー「こう書きます」

// コンストラクタ
public FoolishForm()
{
    // 問題ない
    button.Click += this.Button_Click;
}

// voidでいい / Task返さないので～Asyncも不要
public async void Button_Click(object sender, EventArgs e)
{
    // データを得る
    var data = await this.FetchDataAsync();
    // テキストボックスに反映
    this.textBox.Text = data;
}

Sync氏「え、でも非同期処理ではTaskを返さなければならないのでは？」

レビュアー「この場合だけ、つまりイベントハンドラだけ、async voidを使えます。この場合だけと考えてほぼOKです。他では使わないでください」

数分後…

Sync氏「試してみたら固まらなくなりました！ただ、動いているときにボタンを連打すると、何度もサーバーにアクセスしてしまうのですが」

レビュアー「古典的なJavaScriptの問題と同じで、アクセス中にボタンをクリックできないように仕様変更して下さい。実装はこんな感じにすれば良いと思います」

// ボタンがクリックされたら、データを取得して反映
public async void Button_Click(object sender, EventArgs e)
{
    // まずボタンをクリックできなくする
    this.button.IsEnabled = false;

    try
    {
        // データを得る
        var data = await this.FetchDataAsync();
        // テキストボックスに反映
        this.textBox.Text = data;
    }
    finally
    {
        // ボタンをクリック可能にする
        this.button.IsEnabled = true;
    }
}

Sync氏「ああなるほど！ そうか、ロード中くるくる回るやつを追加で表示したほうが良いかもしれないですね」

レビュアー「そうですね。あと、async voidとする場合は、必ず例外をcatchして下さい」

Sync氏「何故ですか？ 今はApplicationクラスの共通例外ハンドラで処理しているので問題ないと思いますが…」

レビュアー「その例外は、共通例外ハンドラでは処理できません。見たことの無い例外がデバッガのログに出てませんでしたか？」

Sync氏「ああ… UnobservedTaskExceptionというのが出てました。それも変なタイミングで表示されていた気がします」

レビュアー「私はこれから出張があるので詳しくは省きますが、メソッド内でcatchして処理するのがベストです」

（補足: この事については、別に記事を書きましたので、興味があれば参照してください）

Day 8 – サーバーサイドの真実

さらに数日後…

Sync氏「サーバー側の実装もわかりました、前は呼び出し元はこうしていたのですが」

[HttpPost]
public string GetData()
{
    // データを得る
    var data = this.FetchData();
    // テキストボックスに反映
    this.textBox.Text = data;
}

Sync氏「こうすれば良いという事ですね？」

// APIエンドポイント名にAsyncとついていても、自動的に無視される
[HttpPost]
public async Task<string> GetDataAsync()
{
    // データを得る
    var data = await this.FetchDataAsync();
    // 返却する
    return data;
}

レビュアー「はい、それで良いと思います」

Sync氏「GUI側と違って、サーバー側の実装は特に変わったことは無いんですね… もう一つだけ、わからない事があるんですが」

レビュアー「なんですか？」

Sync氏「今回の非同期処理対応で、結局Task.Runメソッドを使わなかったのですが、あれはいつ使うものなのですか？ C#の非同期処理についてググってみると、大体Task.Runを使う例が載っているので使おうとしてああいうコード書いてしまったんですが…」

レビュアー「大量の計算だけを行う処理を並行して同時に処理させたい時だけに使います。我々が普段書いているコードで、そういう処理は殆ど無いですよね？ なので、知らなくても良いレベルで使わない筈です」

（注意: 初稿ではHttpPost属性でAsyncを付けていない名前を明示していましたが、不要でした。Ovisさん、ありがとう）

輝かしい未来への第一歩

Sync氏に横たわっていた暗い霧は、今晴れわたった。そこにはまだ何も存在しないが、やっとスタート地点に立った。そう感じたのである…

お約束の…

ここで挙げた例は、どうしてTask.RunやTask.Resultを使いたがってしまうのかという所に焦点を当てているため、実際にはもっと効率の良い実装テクニックが色々ありますが、最低限このように書けば、Taskをいじり倒して溶岩地帯に突っ込んで死亡する、ということは無くなると思います。なお、ASP.NET (Core), WinForms, WPF, Xamarinについて取り上げましたが、これらだけに適用される手法ではなく、コマンドラインプログラムやUnity、独自の.NET環境など、すべての.NETの非同期処理で適用できる手法です。

もう少しかっちりした解説が必要なら、こちらを参照してください。

では、いつものやつ、行ってみましょう:

Task.Run()も、Task.Factory.StartNew()も、Task.Start()も、Task.ContinueWith()も、Task.Wait()も、Task.Resultも出ませんでしたね？ これらを使う事はまずありません（断言）。

今、記事冒頭の「結論」の項を読み返せば、納得できると思います。「C# 非同期処理」とか「C# async await」などでググってみると、Task.Run()やTask.Resultを最初に説明したり引き合いに出す記事の何と多い事か… これらは本当に、知らなくて良いんですよ。

もし、自信が無くなってきたら、JavaScriptにもPromiseとasync-await構文があるのに、これらに該当するものは無くても実用出来ているということを思い出すと良いと思います。

（更に補足すると、.NET/C#の場合は、async-awaitよりも先にTaskが生まれてしまった事が、不幸の始まりだったのです）

（≒構造上の欠陥という認識

— Kouji Matsui (@kekyo2) February 21, 2022

この記事で少しでも救われる人が増えますように。

それではまた。

ヤヴァいタイトル付けてしまった…. ええと、これはAdvent Calendarではありませんが、勢いで書いています（C# ADは既に埋まっていた…）

それには、こんな事情があったのです:

• 「.NET非同期処理(async-await)を制御する、様々な方法」の記事がコンスタントにPVを稼いでいる
  （その割に、他の非同期関連の記事は読まれない）。
• asyncやawaitキーワードの使い方を度々聞かれる。
• Task.Wait()とか、Task.Resultとか使ってるコードを頻繁に見る（不要なのに！ しかも、この記事を参照しながら全部Wait()とかResultしているブログ記事… そしてそこから流入するPV… 死んじゃう、死んじゃうよ…）。
• Task.Run()とか、Task.Factory.StartNew()とか、Task.Start()とか、Task.ContinueWith()を使ってるコードを頻繁に見る（不要なのに）。
• いまだにThreadクラス直接使ってる… しかもその中でTask.Wait()とか（？！？！）

私のセッションや記事は、「なぜなのか」を深掘りして問題の根本を理解してもらう事を念頭に置いているのですが、さすがにこれだけ頻出してるのは、いろいろ問題があるんじゃないだろうかと思いました。特にXamarinや.NET Coreが注目されると、今までC#でコード書いた事が無い、と言う人が、見よう見まねで書き始める時期じゃないかと思います（それで何となく書けてしまうのが、C#の間口の広いところではあるのですが）。

「できる（なんちゃら）」じゃないけど、そういう資料も切り口を丁寧に詰めればありかも知れない…

そういうわけで:

• C#の非同期処理(Taskとasync-await)を使ってコードを書くなら、以下の事を知っていれば9割がたの問題は回避できる！！
• ここで示した方法から外れたことをしようとしている場合は、殆ど間違いなく誤った記述をしようとしているので、もう一度何をしようとしているのか整理しよう！！

2021.2: これとは別の切り口、「非同期処理、何もわからない」という、開発の日常風に書いたものもあります。こちらの方が分かりやすい人もいるかも知れません。

章立てを二章だけにして、極限まで絞り込みました。ではどうぞ。

# 補足: コードはやや冗長に書いています。

第一章. 同期処理と非同期処理を対比させて、書き方を把握する

以下のコードは、ウェブサイトから「同期的に」データをダウンロードします。要するに、普通のコードです。WebClientクラスを使い、OpenReadメソッドでStreamを取得して、StreamReaderで文字列として読み取ります（クラス定義などは省略）:

using System.IO;
using System.Net;

public static string ReadFromUrl(Uri url)
{
	using (WebClient webClient = new WebClient())
	{
		using (Stream stream = webClient.OpenRead(url))
		{
			TextReader tr = new StreamReader(stream, Encoding.UTF8, true);
			string body = tr.ReadToEnd();
			return body;
		}
	}
}

public static void Download()
{
	Uri url = new Uri("https://github.com/Microsoft/dotnet/blob/master/README.md");
	string body = ReadFromUrl(url);
	Console.WriteLine(body);
}

これを非同期処理として変形します。変形した箇所にはコメントを入れておきました。番号の順にやればスムーズに行くと思います:

using System.IO;
using System.Net;
using System.Threading.Tasks;

// Step5: メソッド内でawaitキーワードを使ったら、メソッドの先頭でasyncを加えなければならない。
// Step6: メソッド内でawaitキーワードを使ったら、戻り値の型はTask<T>型で返さなければならない。
//        T型は本来返すべき戻り値の型。
// Step7: 非同期処理対応メソッドは、「慣例」で「～Async」と命名する（慣例なので必須ではない）。
public static async Task<string> ReadFromUrlAsync(Uri url)
{
	using (WebClient webClient = new WebClient())
	{
		// Step1: OpenReadから非同期対応のOpenReadTaskAsyncに変更する。
		// Step2: OpenReadTaskAsyncがTask<Stream>を返すので、awaitする。
		//        awaitすると、Streamが得られる。
		using (Stream stream = await webClient.OpenReadTaskAsync(url))
		{
			TextReader tr = new StreamReader(stream, Encoding.UTF8, true);
			// Step3: ReadToEndから非同期対応のReadToEndAsyncに変更する。
			// Step4: ReadToEndAsyncがTask<string>を返すので、awaitする。
			//        awaitすると、stringが得られる。
			string body = await tr.ReadToEndAsync();
			return body;
		}
	}
}

// Step10: メソッド内でawaitキーワードを使ったら、メソッドの先頭でasyncを加えなければならない。
// Step11: メソッド内でawaitキーワードを使ったら、戻り値の型はTask型で返さなければならない。
//         ここでは元々返す値が無かった(void)なので、非ジェネリックなTask型を返す。
// Step12: 非同期処理対応メソッドは、「慣例」で「～Async」と命名する（慣例なので必須ではない）。
public static async Task DownloadAsync()
{
	Uri url = new Uri("https://github.com/Microsoft/dotnet/blob/master/README.md");
	// Step8: ReadFromUrlから非同期対応のReadFromUrlAsyncに変更する。
	// Step9: ReadFromUrlAsyncがTask<string>を返すので、awaitする。
	//        awaitすると、stringが得られる。
	string body = await ReadFromUrlAsync(url);
	Console.WriteLine(body);
}

# 補足: HttpClientではなくWebClientを使ったのは、対比させやすいためです。非同期前提で書くなら、始めからHttpClientを使うと良いでしょう。WebClientの代わりにHttpClientで同じ処理を書いてみるのは、良い練習になると思います。

出来るだけわかりやすくなるようにコメントを入れたので、「ひたすらめんどくさそう」に見えますが、よく見れば大した作業ではない筈です。ReadFromUrlとDownloadのそれぞれのメソッドが、どのように変形されるのかを見てください。そうすると何となく法則が見えてくると思います。

また、この作業で、2つのメソッド「ReadFromUrl」と「Download」が、両方とも非同期メソッド化された事にも注意してください。

// これはWPFのウインドウ実装です（但し、WPFであることはあまり重要ではありません）:
public partial class MainWindow : Window
{
    // 参考:
    //   Window.Loadedイベントの定義:
    //     public event RoutedEventHandler Loaded;
    //   RoutedEventHandlerデリゲートの定義:
    //     public delegate void RoutedEventHandler(object sender, RoutedEventArgs e);

    // コンストラクタ
    public MainWindow()
    {
        InitializeComponent();

        // ウインドウ表示開始時のイベントをフックする
        this.Loaded += MainWindow_Loaded; 
    }

    // ウインドウが表示されると呼び出される
    private void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        // 第1章で実装したReadFromUrlを呼び出して、テキストボックスに表示する
        Uri url = new Uri("https://github.com/Microsoft/dotnet/blob/master/README.md");
        string body = ReadFromUrl(url);
        textBox.Text = body;
    }
}

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        this.Loaded += MainWindow_Loaded; 
    }

    // Step3: メソッド内でawaitキーワードを使ったら、メソッドの先頭でasyncを加えなければならない。
    // Step4: メソッド内でawaitキーワードを使ったら、戻り値の型はTask型で返さなければならない。
    //        しかし、Loadedイベントのシグネチャは変更できない。従って「void」のままとする。
    // Step5: 非同期処理対応メソッドは、「慣例」で「～Async」と命名する。
    //        しかし、値を返さないためawait忘れの可能性はない事と、あくまで慣例であるため
    //        ここでは「～Async」と命名しない。
    private async void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        Uri url = new Uri("https://github.com/Microsoft/dotnet/blob/master/README.md");
        // Step1: ReadFromUrlから非同期対応のReadFromUrlAsyncに変更する。
        // Step2: ReadFromUrlAsyncがTask<string>を返すので、awaitする。
        //        awaitすると、stringが得られる。
        string body = await ReadFromUrlAsync(url);
        textBox.Text = body;
    }
}

// コンソールアプリケーションのメインエントリポイント
// awaitを使っているのでasyncを追加する（？）
public static async void Main(string[] args)
{
    // Task型が返されるので、この処理を待機するためawaitする（？）
    await DownloadAsync();
}

// コンソールアプリケーションのメインエントリポイント
public static void Main(string[] args)
{
    // Step1: Task.Wait()を使わざるを得ない。
    Task task = DownloadAsync();
    task.Wait();
}

// コンソールアプリケーションのメインエントリポイント
// C# 7.1以上を使うなら、MainがTaskを返す事が出来る
public static async Task Main(string[] args)
{
    // 普通にawait出来る。Task.Wait()の呼び出しは不要
    await DownloadAsync();
}

数回に分けて、継続についてのもろもろを、時系列にそって書きます。

そもそも「継続」という学問があるようなのですが、私はここ最近に至るまでそんな学問があるとも知らずに継続を扱ってきたこともあって、きっと厳密性は全く無いと思います。ただ、経験から得られた知識であれど、実際に動作させたという知見があるので、もしそういった方からのアプローチが役に立つのであればそれはそれでいいんじゃないかという妄想によりますので、控えめによろしくお願いします (;´Д｀)

@pocketberserker gkbr

— kekyo (@kekyo2) 2016年3月22日

※そこんとこは「継続」で言うところの何某だよ、みたいなコメントがあると嬉しいです

ちなみに、近日「継続勉強会」があるようです。うぅ、東京うらやましい…

code	segment byte public
	assume cs:code, ds:data

public	transfer

trans_stack	struc	; arguments of transfer.
tr_bp	dw	?
return	dd	?
proc2	dd	?
proc1	dd	?
trans_stack	ends

transfer proc far
	push	bp
	mov	bp, sp
	les	di, [bp].proc1
	mov	es:[di], sp	；現在のスタックポインタをproc1が示すtrans_stackに保存
	mov	es:[di+2],ss	
	cli
	mov	sp, word ptr [bp].proc2	; proc2が示すtrans_stackのポインタをスタックポインタに設定
	mov	ss, word ptr [bp].proc2+2
	sti
	pop	bp
	ret	8
transfer endp

code	ends
	end

	; @tempというレジスタがあったと仮定して:
	pop	@temp
	jmp	@temp

// 疑似コードです。動きません
extern void transfer(trans_stack* fromtr, trans_stack* totr);

static trans_stack main_tr;
static trans_stack sub_tr;

// subのtransfer-processエントリポイント
static void sub()
{
  auto i = 1000;
  while (1)
  {
    printf("sub(): %d\n", i++);

    // subからmainに転送
    transfer(&sub_tr, &main_tr);
  }
}

// main（のtransfer-process）
void main()
{
  // bpの初期値は0で良い
  sub_tr.tr_bp = 0;
  // transfer-processの初期位置はsub関数の先頭
  sub_tr.return = ⊂
  // subのためのスタックを確保
  sub_tr.proc2 = malloc(0x1000);

  for (auto i = 0; i < 10000; i++)
  {
    printf("main(): %d\n", i);

    // mainからsubに転送
    transfer(&main_tr, &sub_tr);
  }
}

Taskクラスとasync-awaitを使用して非同期処理を記述する場合の、例外にまつわるあれこれをまとめました。

概要：

• 表面上は殆ど変らない
• 現実の動作
• タスクコンテキストとスレッドコンテキスト
• スタックウォーク
• 処理されない例外

この記事は、非同期処理と例外処理について、多少難易度の高い話題を含みます。もし、もっと基本的な記述方法や、安全に例外を処理する方法を知りたい場合は、この記事をお勧めします: 「.NET非同期処理で例外を安全に対処する」

この記事の前に、非同期処理の基本を扱った記事もあります: 「.NET非同期処理(async-await)を制御する、様々な方法」

非同期処理中に発生する例外の捕捉

非同期処理中に発生する例外を捕捉する方法は、一般的な例外の捕捉とほとんど変わりません。

// 指定されたURLからHTMLコンテンツをダウンロードする
public static async Task<XElement> StartFetchContentAsync(Uri url)
{
	using (var httpClient = new HttpClient())
	{
		try
		{
			// HTTP GETでURLに非同期的に要求する
			using (var stream = await httpClient.GetStreamAsync(url))
			{
				// （パース）
				return SgmlReader.ParseXElement(stream);
			}
		}
		// 非同期処理中（又は同期処理中）に発生した例外を捕捉
		catch (Exception ex)
		{
			// 何かエラー処理
			logger_.WriteLog(ex.Message);
			// 再スロー
			throw;
		}
	}
}

上記のコードにより：

• GetStreamAsync非同期メソッドの完了待機中（await）に発生した例外の捕捉
• それ以外の例外（例：SgmlReaderのパース）の捕捉

の両方とも、catch構文で例外を捕捉出来ます。
上記の例では示しませんが、C#5.0では、catchブロック中（又はfinally）で更に非同期メソッドを呼び出して待機（await）することは出来ません。C#6.0では可能です。

Task.WhenAllを使って非同期処理を集約している場合、一度に複数の例外が発生するかもしれないため、発生した例外は「AggregateException」クラスに内包されてスローされます。

// 指定されたURL群からHTMLコンテンツをダウンロードする
public static async Task<XElement[]> StartFetchContentsAsync(IEnumerable<Uri> urls)
{
	try
	{
		return await Task.WhenAll(
			urls.Select(async url =>
			{
				using (var httpClient = new HttpClient())
				{
					// HTTP GETでURLに非同期的に要求する
					using (var stream = await httpClient.GetStreamAsync(url))
					{
						// （パース）
						return SgmlReader.ParseXElement(stream);
					}
				}
			}));
	}
	// Task.WhenAllで発生した例外を捕捉
	catch (AggregateException ex)
	{
		// 何かエラー処理
		ex.InnerExceptions.ForEach(iex => logger_.WriteLog(iex.Message));
		// 再スロー
		throw;
	}
}

非同期処理の遷移

上記のように、非同期メソッドを呼び出して例外を処理するコードを書いても、表面上は同期メソッド呼び出しと殆ど変りません。また、実際に考慮すべき事も殆ど変りません。しかし、内部で発生している例外がどのように処理されているのかという点では、かなり異なります。

以下の図を見て下さい：

（なお、まるでこれがHttpClientの実装であるかのように書いていますが、実際のHttpClientは別の手法で実現している可能性があります）

これは、非同期メソッドではなく、同期メソッドでの例外のフローです（疑似的に、HttpClientに「GetStream」という同期メソッドがあると仮定して書いています。実際にはありません）。

GetStreamを呼び出したものの、指定されたURLに接続出来なかったり、HTTPサーバーがエラーを返すなどした場合、メソッド内で例外がスローされます。それはそのまま呼び出し元のcatchブロックでキャッチされます。当たり前ですが、この時の呼び出し元スレッドの実行パスは、赤い矢印で図示した通りの経路をたどります。

では、非同期メソッドを呼び出した場合はどうなるでしょうか？

public static void RethrowExceptionSample()
{
	try
	{
		// 何らかの処理
		throw new Exception();
	}
	catch (Exception ex)
	{
		// 例外の処理
		logger_.WriteLog(ex);

		// 再スロー（ここからスタックトレースが再構築されてしまう）
		throw ex;
	}
}

public static void RethrowExceptionSample()
{
	try
	{
		// 何らかの処理
		throw new Exception();
	}
	catch (Exception ex)
	{
		// 例外の処理
		logger_.WriteLog(ex);

		// 再スロー（スタックトレースは維持される）
		throw;
	}
}

public static void RethrowAnotherThreadBoundExceptionSample()
{
	// ワーカースレッドで発生した例外を保持する変数
	Exception caughtException= null;

	// ワーカースレッドの生成
	var thread = new Thread(() =>
		{
			try
			{
				// 何らかの処理
				throw new Exception();
			}
			catch (Exception ex)
			{
				// 例外を記録
				caughtException = ex;
			}
		});

	// ワーカースレッドの実行と完了の待機
	thread.Start();
	thread.Join();

	// ワーカースレッドで例外が発生していたら
	if (caughtException != null)
	{
		// error CS0156: 引数なしの throw ステートメントは catch 句以外では使えません。
		throw;
		// スタックトレースを失う
		// throw caughtException;
	}
}

// CLR 4.0以降
public static Task RethrowAnotherThreadBoundExceptionSampleAsync()
{
	// タスクコンテキストの拠り所を生成
	var tcs = new TaskCompletionSource<object>();

	// ワーカースレッドの生成
	var thread = new Thread(() =>
	{
		try
		{
			// 何らかの処理
			throw new Exception();
		}
		catch (Exception ex)
		{
			// 例外を通知
			tcs.SetException(ex);
		}
	});

	// ワーカースレッドの実行
	thread.Start();

	// Taskを返す
	return tcs.Task;
}

static void Main(string[] args)
{
	try
	{
		// タスクの完了をハードウェイトする
		RethrowAnotherThreadBoundExceptionSampleAsync().Wait();
	}
	catch (Exception ex)
	{
		Debug.Assert(ex.GetType() == typeof(AggregateException));
		Console.WriteLine(ex.ToString());
	}
}

// 非同期待機（await）出来るようにするため、非同期メソッドを定義
public static async Task CallerAsync()
{
	try
	{
		// 非同期メソッドを呼び出して非同期的に待機
		await RethrowAnotherThreadBoundExceptionSampleAsync();
	}
	catch (Exception ex)
	{
		Debug.Assert(ex.GetType() == typeof(Exception));
		Console.WriteLine(ex.ToString());
	}
}

static void Main(string[] args)
{
	CallerAsync().Wait();
}

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	try
	{
		// 非同期処理を開始
		var task1 = stream1.WriteAsync(data1, 0, data1.Length);
		var task2 = stream2.WriteAsync(data2, 0, data2.Length);

		// それぞれの完了を待機
		await task1;
		await task2;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}
}

<configuration> 
	<runtime> 
		<ThrowUnobservedTaskExceptions enabled="true"/> 
	</runtime> 
</configuration>

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	// 非同期処理を開始
	var task1 = stream1.WriteAsync(data1, 0, data1.Length);
	var task2 = stream2.WriteAsync(data2, 0, data2.Length);

	try
	{
		// task1の完了を待機
		await task1;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}

	try
	{
		// task2の完了を待機
		await task2;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}
}

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	// 非同期処理を開始
	var task1 = stream1.WriteAsync(data1, 0, data1.Length);
	var task2 = stream2.WriteAsync(data2, 0, data2.Length);

	try
	{
		// task1とtask2のの完了を同時に待機
		await Task.WhenAll(task1, task2);
	}
	catch (Exception ex)
	{
		// （非同期例外であれば、AggregateExceptionに内包されている）
		Console.WriteLine(ex.ToString());
	}
}

async-awaitベースの非同期処理を制御する方法をまとめました。コードはわざと冗長に書いています。

概要：

• Taskベースのワーカースレッド生成
• 他の非同期I/Oと連携してタスクを制御する方法
• TaskとLINQを応用して、多量の計算を安全に並列実行させる方法
• Taskを使っていない非同期処理をTask化する方法
• 非同期処理のキャンセルの実現方法
• WinRT・ユニバーサルWindowsアプリケーション（UWP)での非同期処理とTaskの連携方法

読む前に補足

C#でTaskやasync-awaitを使った非同期処理の書き方を探しているのであれば、ポイントに絞って書いた、こちらの記事をお勧めします: 「できる！C#で非同期処理(Taskとasync-await)」

Taskクラスの使用例として、ワーカースレッドを起動するという例が良く挙げられます。本記事も最初にTask.Runによるワーカースレッドの例を紹介していますが、本来のTaskクラスの役割はワーカースレッドの管理ではなく、非同期処理の統一された操作にあります（非同期I/Oもワーカースレッドも同じように「非同期処理」として管理可能にする）。

また、async-awaitの使い方を調べていてこの記事にたどり着いた場合は、「基本的にTask.Runは使わない」と言う事を頭の片隅に置いておいて下さい。特殊な場合を除いて、明示的にTask.Runでワーカースレッドを操作する必要はありません。非同期メソッドが返すTaskクラスをawaitする事に集中すれば、問題なくコードを記述できる筈です。

違いが分からなくなったり混乱した場合は、この前提を思い出してみて下さい。

この記事の続きとして、非同期処理における例外を扱った記事もあります: 「.NET非同期処理(async-await)と例外の制御」

Task.Runの基礎

TaskクラスのRunメソッドを使用すると、ワーカースレッドを使用して独自の処理を非同期化（タスク化）出来ます。

public static async Task SampleTaskRun1Async()
{
	// ワーカースレッドが生成される
	Task task = Task.Run(new Action(() =>
		{
			// 任意のCPU依存性処理...
		}));

	// 処理が完了するのを非同期的に待機
	await task;

	Console.WriteLine("Done!");
}

Task.Runメソッドは、.NET4.5未満ではTask.Factory.StartNewと同じです。

Task.Runを使用した場合、戻り値としてTaskクラスのインスタンスが取得出来ます。
従来は、Threadクラスを使用してワーカースレッドを直接生成して管理していましたが、Task.Runで返却されたTaskを使用すれば、非同期処理と同じようにワーカースレッドの操作を待機する事が出来ます。

また、Threadクラスを使った場合、ワーカースレッドの待機は、Thread.Joinメソッドを使いますが、このメソッドはハードブロックしてしまいます。非同期処理の世界で行儀よく振る舞うためには、待機すべきあらゆる箇所でTaskクラスが必要となります。

# 厳密にはGetAwaiterメソッドの実装が担保しますが、細部なので省略。また、WinRTでは、IAsyncActionやIAsyncOperationでも待機出来ます（後述）

Taskを使用する優れた点は、他のタスクとの合成が簡単であることです。

public static async Task SampleTaskRun2Async(Stream dataStream, byte[] data)
{
	Task task1 = Task.Run(new Action(() =>
		{
			// 任意のCPU依存性処理...
		}));

	Task task2 = Task.Run(new Action(() =>
		{
			// 他の任意のCPU依存性処理...
		}));

	// ネイティブな非同期I/O処理
	Task task3 = dataStream.WriteAsync(data, 0, data.Length);

	// 全ての処理が完了するのを非同期的に待機
	Task combinedTask = Task.WhenAll(task1, task2, task3);
	await combinedTask;

	Console.WriteLine("All done!");
}

Task.WhenAllメソッドは、指定されたタスク群が全て完了するのを待機する、新しいTaskを返します。
上記のように、CPU依存性の（つまり、ワーカースレッドで実行する）非同期処理と、ネイティブなI/O操作の非同期処理を、全く同じように扱う事が出来ます。

Task.Runを使うと簡単にワーカースレッドを制御出来るので、従来のThreadクラスは、

• スレッド名を割り当てる必要がある
• COMアパートメントを設定する必要がある
• スレッドローカルストレージに残骸が残るような状況を完全に破棄したい

と言うような場合にだけ使用すれば良いでしょう。

Task.Runの戻り値

Task.Runは戻り値を返すことが出来ます。

public static async Task SampleTaskRun3Async(int count)
{
	// Func<T>デリゲートを使用することで、処理の戻り値を返す事が出来る
	Task<double> task = Task.Run(new Func<double>(() =>
		{
			// 任意のCPU依存性処理...
			var r = new Random();
			return Enumerable.Range(0, count).Select(index => r.Next()).Average();
		}));

	// 処理が完了するのを非同期的に待機
	double result = await task;

	Console.WriteLine("Done: {0}", result);
}

Task.Run引数のデリゲートが戻り値を返す「Func<T>」である場合、返されるTaskも「Task<T>」となり、awaitすると戻り値が返されます。

Task.WhenAllで、結果の集約

戻り値を返すタスクと、Task.WhenAllとLINQを使って応用すると、大量のデータを効率よくワーカースレッドに流し込んで並列実行させ、かつ全て完了するのを待機するという、今までなら出血しそうなコードが、非常に簡単に安全に記述出来ます。

public static async Task SampleTaskRun4Async(int count)
{
	// 計算を非同期に実行するタスクを、count個列挙する
	// 1, 1+2, 1+2+3, 1+2+3+4, ...
	IEnumerable<Task<long>> tasks =
		Enumerable.Range(1, count).
		Select(index => Task.Run(() => Enumerable.Range(1, index).Sum(v => (long)v)));

	// 全ての処理が完了するのを非同期的に待機
	long[] results = await Task.WhenAll(tasks);

	Console.WriteLine("Done: [{0}]", string.Join(",", results));
}

慣れていないと分かり難いかも知れません。この処理は、以下のように動作します。

この方法は、タスク（中身はワーカースレッド）を指定された個数分起動し、全てが完了するのを待ちます。直感的には、大量のワーカースレッドが生成され、コンテキストスイッチングで飽和してまともに動作しないように見えますが、実際はそうなりません。Task.Runは、スレッドプールからワーカースレッドを取得しますが、スレッドプールの総スレッド数は、効率よく実行できる程度に調整されています（図の例では、最大で4個のスレッドが次々と計算を処理します）。

このスクリーンショットは、Process Explorerでスレッドに割り当てられているCPUサイクルを見たものです。このテストを実施したマシンは、4コア2論理スレッドなので、システム上は8スレッド使えます。実際にほぼ8スレッドだけがアクティブに動作し、大量のワーカースレッドで飽和する事が無い事が分かります。

PLINQ（並列LINQ）と比べると、タスクを集約可能な式として実装する必要があるため、PLINQのように自然に拡張する事は出来ませんが、パフォーマンスの予測がしやすい事が利点です。

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
private async void OnInitialized(object sender, EventArgs e)
{
	// 文字列を返すことが出来るTaskCompletionSourceを準備
	var tcs = new TaskCompletionSource<string>();

	// ボタンがクリックされたら、テキストボックスの文字列をTaskCompletionSourceを介して間接的に返却する
	button.Click += (s, e) => tcs.SetResult(textBox.Text);

	// 非同期で待機する
	string inputText = await tcs.Task;

	// 結果をテキストブロックに表示
	textBlock.Text = inputText;
}

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// ボタン1がクリックされたら、テキストボックス1の文字列をTaskCompletionSourceを介して間接的に返却する
	var tcs1 = new TaskCompletionSource<string>();
	button1.Click += (s, e) => tcs1.SetResult(textBox1.Text);

	// ボタン2がクリックされたら、テキストボックス2の文字列をTaskCompletionSourceを介して間接的に返却する
	var tcs2 = new TaskCompletionSource<string>();
	button2.Click += (s, e) => tcs2.SetResult(textBox2.Text);

	// 両方のボタンがクリックされるまで待機
	string[] inputTexts = await Task.WhenAll(tcs1.Task, tcs.Task2);

	// 結果をテキストブロックに表示
	textBlock.Text = string.Join(",", inputTexts);
}

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// itemCount_個だけUI部品を生成し、関連付けられたTask群を返す
	IEnumerable<Task<string>> tasks =
		Enumerable.Range(0, itemCount_).
		Select(index =>
		{
			var textBox = new TextBox();
			var button = new Button();
			stackPanel.Children.Add(textBox);
			stackPanel.Children.Add(button);
			
			var tcs = new TaskCompletionSource<string>();
			button.Click += (s, e) => tcs.SetResult(textBox.Text);

			return tcs.Task;
		});

	// 全てのボタンがクリックされるまで待機
	string[] inputTexts = await Task.WhenAll(tasks);

	// 結果をテキストブロックに表示
	textBlock.Text = string.Join(",", inputTexts);
}

// COMアパートメントを指定して、独立したワーカースレッドを実行する
public static Task<TResult> RunEx<TResult>(
	Func<TResult> action,
	ApartmentState state = ApartmentState.STA)
{
	// スレッド終了を通知するTaskCompletionSource
	var tcs = new TaskCompletionSource<TResult>();

	// ワーカースレッドを生成する
	var thread = new Thread(new ThreadStart(() =>
		{
			try
			{
				// 処理本体を実行して、戻り値を得る
				var result = action();

				// Taskに終了を通知
				tcs.SetResult(result);
			}
			catch (Exception ex)
			{
				// 例外をTaskに通知
				tcs.SetException(ex);
			}
		}));
	thread.SetApartmentState(state);
	thread.Start();

	// Task<TResult>を返す
	return tcs.Task;
}

// 指定されたデータをストリームに指定回数出力する
public static async Task SampleTaskRun5Async(
	Stream stream,
	byte[] data,
	int count,
	CancellationToken token)
{
	for (var index = 0; index < count; index++)
	{
		// キャンセル要求があれば、例外をスローして中断する
		token.ThrowIfCancellationRequested();

		// 非同期I/O処理も、中断を可能にする
		await stream.WriteAsync(data, 0, data.Length, token);
	}
}

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// CancellationTokenSourceクラスを準備（これでキャンセルを通知出来る）
	var cts = new CancellationTokenSource();

	// ボタンがクリックされたら、キャンセルを通知する
	button.Click += (s, e) => cts.Cancel();

	try
	{
		// 時間のかかる非同期処理にキャンセルトークンを渡す
		Task task = SampleTaskRun5Async(stream_, data_, 100000, cts.Token);

		// 非同期で待機する
		await task;

		// 結果をテキストブロックに表示
		textBlock.Text = "Output completed!";
	}
	catch (OperationCancelledException)
	{
		// 結果をテキストブロックに表示
		textBlock.Text = "Output canceled...";
	}
}

// 指定されたデータをストリームに指定回数出力する
public static async Task SampleTaskRun6Async(
	Stream stream,
	byte[] data,
	int count,
	CancellationToken token)
{
	// キャンセル要求に対して、コールバックで反応する
	// （下記の実処理とは無関係に、キャンセル時にコールバックが発生する）
	var index = 0;
	token.Register(() =>
		// （実際にはここでキャンセル処理を行う）
		Console.WriteLine("Operation canceled: Written count={0}", index));

	// 実処理
	for (; index < count; index++)
	{
		token.ThrowIfCancellationRequested();
		await stream.WriteAsync(data, 0, data.Length, token);
	}
}

// WinRT非同期処理群を待機して、結果をテキストブロックに反映する
public static async Task SampleTaskRun7Async(IEnumerable<IAsyncOperation<string>> asyncOperations)
{
	// IAsyncOperation<string>をTask<string>に変換
	// （WindowsRuntimeSystemExtensions.AsTask拡張メソッド）
	IEnumerable<Task<string>> tasks =
		asyncOperations.Select(asyncOperation => asyncOperation.AsTask());

	// すべてが完了するのを待機出来るタスクに変換
	Task<string[]> combinedTask = Task.WhenAll(tasks);

	// 完了を待つ
	string[] results = await combinedTask;

	// 結果を反映
	textBlock.Text = string.Join(",", results);
}

… ネタが降ってきた (;´Д｀)

.NETのコンソールプログラムは、Visual Studioで普通に作ると、以下のようなテンプレコードが生成されます。

namespace ConsoleApplication2
{
	internal static class Program
	{
		public static int Main(string[] args)
		{
			return 0;
		}
	}
}

勉強会のasync/awaitシリーズで説明したシチュエーションは、WPFやWinFormsという環境での話でした。そこでは、「UIキュー」が重要で、このキューに非同期処理の完了が放り込まれ、メインスレッドがこれを拾い上げて処理する事で、await以降の処理が実行されることを説明しました。

コンソールで実行されるコードの場合、この「UIキュー」が存在しません（WPFやWinFormsのインフラを使った場合は生成されますが、ここでは扱いません）。そのため、await時に「ハードウェイト」しても困らない事になります。

UIキューが存在する環境でハードウェイトすると、UIキュー内のエントリが実行されなくなります。目に見える問題として、ユーザーの操作（ウインドウを移動したりサイズ変更したり、ユーザーインターフェイス要素の操作）が無視され、アプリケーションが固まっているように見えます。

しかし、コンソールアプリケーション実行時のウインドウ「コマンドプロンプト」は、アプリケーションのスレッドの状態に関わらず、常に操作可能です。以下のProcessExplorerのスクリーンショットは、コマンドプロンプトウインドウを激しく動かしている時に撮ったものです。

コンソールアプリケーション（ここではcmd.exe）を起動すると、同時に子プロセスとして「conhost.exe」が起動します。はっきりしたことは分かりませんが、上記のようにウインドウの操作を行うと、このconhost.exeの負荷が上昇する事から、ウインドウメッセージの処理はこのプロセスが受け持っている事が推測できます。そうであれば、実際のコンソールアプリケーションは、UIキューの処理に影響される事無く（元々持っていない）、そしてユーザーインターフェイスがブロックされる事が無く、動作するのです。

話を戻して、コンソールアプリケーションではUIキューを持っていないので、スレッドがハードブロックしても問題ありません。Taskクラスを返却する「非同期メソッド」は、必要な個所でハードブロック出来ます。この事を利用して、以下のようなスケルトンコードを考える事が出来ます。

namespace ConsoleApplication2
{
	internal static class Program
	{
		private static async Task<int> InternalMainAsync(string[] args)
		{
			// あんな非同期やこんな非同期処理 ...

			// Console.WriteLineへのアクセスはスレッドコンテキスト違反にはならない
			Console.WriteLine("async/await on Console Application.");
		}

		public static int Main(string[] args)
		{
			try
			{
				return InternalMainAsync(args).Result;
			}
			catch (Exception ex)
			{
				Console.Error.WriteLine(ex.ToString());
				return Marshal.GetHRForException(ex);
			}
		}
	}
}

Mainの最初の処理として、InternalMainAsyncメソッドを呼び出します。このメソッドはTaskクラスを返却する非同期メソッドです。そのため、このまま放置すると次の処理に行ってしまいます（Mainを抜けて終了してしまう）。そのため、Waitを呼び出してハードブロックする必要があります。上記の例ではResultプロパティを呼ぶことで、間接的にハードブロックしています（戻り値intを取得するため）。

一方、InternalMainAsyncの中の処理は全て非同期で記述できます。ここでの知識は、WPFやWinFormsで非同期処理を記述する時と全く同じ知識を活用できます。言い換えると、普段から非同期処理を書いているなら、同じ流れで書いて問題ないという事です。

スレッドはどうなるのか？ ですが、メインスレッドとUIキューの関係は無く、メインスレッドはResultでハードブロックしているので、全ての非同期処理（非同期処理の継続操作）はワーカースレッドのコンテキストで駆動されます。

今話題にしているのはコンソールアプリケーションでしたね？ 例えば、ワーカースレッドからConsole.WriteLineを呼び出しても問題なく出力出来ますね？ 勿論、マルチスレッドアクセスが認められないクラスやメソッド、特定のスレッドコンテキストに紐づくクラス等を扱う場合は、スレッド同期やマーシャリング等の操作が必要になりますが、この辺の知識はTask.RunやThreadクラスを使って手動でワーカースレッドを作った時と同じように考えればOKです。

追記: 現代の話 (2020年)

ネタとしてはもうかなり前から出来るようになっていますが、C# 7.1以上を使用している場合は、以下のように直接MainメソッドがTaskを返すように書く事が出来ます:

namespace ConsoleApplication3
{
	internal static class Program
	{
		public static async Task<int> Main(string[] args)
		{
			// あんな非同期やこんな非同期処理 ...
		}
	}
}

ポイントは、

• メソッド名はMainであること
• 引数は従来通り、無しかstring[]であること
• 戻り値の型がvoidの場合は従来通りの扱い、Task又はTask<int>の場合のみ、Mainを非同期メソッドとして認識

.NET Core/Frameworkのバージョンではなく、C#のバージョンによって使用可能になります。つまり、この機能は、コンパイラが判断して適切なコードを自動生成する事で実現しています。生成されるコードは、私たちが手動で行っていたのと同じように、Wait()やResultを呼び出してハードウェイトしている事になるため、UIキューを使うようなシチュエーションでは使えません。