DEV Community: Joni 【ジョニー】

Visual Guide to C# async/await

Joni 【ジョニー】 — Sun, 04 Jul 2021 22:02:27 +0000

Microsoft first introduced async/await pattern in C# 5.0 back in 2011. I think it’s one of the greatest contributions to the asynchronous programming — at languages level— which led other programming languages to follow, like Python and JavaScript, to name a few. It makes asynchronous code more readable, more like the ordinary synchronous code. Remember those old-school BeginXxx / EndXxx in Asynchronous Programming Model/APM in C# 1.0? I can still remember writing those in 2002 with Visual Studio .NET 2002.

Enough foreword. Do you still remember the famous “There Is No Thread” post from Stephen Cleary?

If you’re newbie to C#, go read it. I will wait. Perhaps, I should say await ReadAsync() ?😆

Okay, I’m glad you’re still here. This post is my attempt to help C# developers to better grasp what async/await is all about.

Synchronous code

Let’s start with the synchronous version.

Visualized: Ordinary, synchronous method call in C#

Nothing fancy here. I guess it’s pretty straightforward and self-explanatory.

Asynchronous code

Next, the asynchronous one.

Visualized: Asynchronous method call in C#

As you can see, our asynchronous chef put await MethodAsync() in the kitchen and then leaves the kitchen without waiting for the 🍜(Task<🍜>) to be ready. Our synchronous chef, whereas, in contrast, will be hanging around, perhaps forever in the kitchen, waiting for the 🍜.

Our asynchronous chef leaves the kitchen, returns to his home (thread pool ), waiting with his lovely family members (thread pool threads ) while keeping the door open (assuming ConfigureAwait(false); trying to simulate “no Synchronization Context” here). At this point, we are in the so-called “there is no thread” state. Nobody is in the kitchen. Our 🍜 is still sitting in the microwave (ongoing I/O operation). Sorry to disappoint you, my dear reader, it’s instant noodles 😂.

Once it’s heated, our super smart AI-powered-alarm-shaped drone (I/O Completion Port — IOCP) flies to our chef’s house to notify them. Remember that the door is left open (again, no Synchronization Context), but our chef is in the toilet 🚽, so he asked his wife — who happened to be a chef as well — to go to continue his work. She resumes her husband’s remaining tasks, picks where her husband left it off (resuming AsyncStateMachine). The rest is the same as the synchronous version.

Visualize using Visual Studio

The animated GIFs are there to illustrate analogies in the our-almost-real-world. Let’s try to visualize it using Visual Studio.

We’ll be using the following code, a minimal APIs, new in .NET 6.

var builder = WebApplication.CreateBuilder(args);
await using var app = builder.Build();

if (app.Environment.IsDevelopment())
{
  app.UseDeveloperExceptionPage();
}

app.MapGet("/sleep", (CancellationToken cancellationToken) =>
{
  while (!cancellationToken.IsCancellationRequested)
  {
    Enumerable.Range(1, 100).Select(x => x).ToList().ForEach(x =>
    {
      //WARNING: BAD CODE
      Task.Run(() => Thread.Sleep(3 * 60 * 1_000), cancellationToken);
    });
    Thread.Sleep(2 * 60 * 1_000);
  }
  return "Done.";
});

app.MapGet("/delay", async (CancellationToken cancellationToken) =>
{
  while (!cancellationToken.IsCancellationRequested)
  {
    Enumerable.Range(1, 100).Select(x => x).ToList().ForEach(x =>
    {
      //WARNING: BAD CODE
      Task.Run(async () => await Task.Delay(3 * 60 * 1_000, cancellationToken), cancellationToken);
    });
    await Task.Delay(2 * 60 * 1_000, cancellationToken);
  }
  return "Done.";
});

await app.RunAsync();

Synchronous code

First, we will inspect the synchronous version. Go to https://localhost:5001/sleep. Inspect the process using Process Explorer.

Inspect using Process Explorer

We can see that we are starting up 100 threads. Notice the scrollbar? We have a bunch of threads hanging around.

📝 Even though we are calling Thread.Sleep, it’s still a waste of resources.

Let’s go back to Visual Studio, use Break All to pause the application execution.

Break All in Visual Studio

📝 You can use Debugger.Break to achieve the same effect. Details: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debugger.break

Look at the Parallel Stacks window.

Parallel Stacks window

A lot of sleeping threads are in “blocked” state. It’s like our synchronous chef in the kitchen doing nothing except waiting for the 🍜 to be heated in the microwave.

Now, switch the View to Threads view to see how it looks, grouped by threads. Hundreds of threads!

View by Threads.

Let’s see Threads window. Notice the scrollbar?

Threads window

Asynchronous code

Next, let’s see asynchronous version. Go to https://localhost:5001/delay. Inspect the process using Process Explorer.

Inspect using Process Explorer

We have started 100 tasks, but hey, there is no scrollbar!

Go back to Visual Studio, pause the application execution.

Break All in Visual Studio

Look at the Parallel Stacks window.

Parallel Stacks window. A bunch of tasks are in “scheduled” state.

Lots of tasks are in a “scheduled” state; scheduled to be fired in the future. In Thread column, you can see that there is no thread info, no thread ID.

Did you just scroll up to double-check the screenshot of the synchronous version? Welcome back! 😆

Now, switch the View to Threads view to see how it looks, grouped by threads.

View by Threads.

Less than ten threads, that’s mostly the framework threads.

Let’s see Threads window. Notice that there is no scrollbar.

Threads window

So yes, there is “no thread” here. No user code thread, to be precise. No thread, no chef. Like our asynchronous chef, instead of waiting in the kitchen, he returns to his home sweet home.

That’s it!

So what does this mean? For ASP.NET, this “ no thread” will translate to a scalability improvement since we don’t block our precious thread pool threads; blocking might lead to thread pool starvation. Here is the analogy. We only have five chefs. All of them are now waiting in the kitchen, doing nothing. We can no longer process additional cooking orders. But if they don’t simply wait in the kitchen, they would be able to process the same amount of orders with, say, just only two chefs. Given that two busy chefs in the kitchen, we still have three remaining chefs idle, waiting for the new additional cooking orders.

VS Code の Remote Repositories はいいぞ。その他の便利なツールを比較してみた。

Joni 【ジョニー】 — Mon, 14 Jun 2021 16:19:23 +0000

VS Code version 1.57 で Remote Repositories の拡張機能をインストールすることで、 GitHub 上のリポジトリをローカルにクローンしなくても、コードの参照はもちろん、検索と更新（プッシュ）もシームレスに可能になりました。

実は VS Code Insiders で最初に使えた機能で、それでしばらく使っていました。 Stable に早くも使えるなんて嬉しいですね。 Insiders でドラフトで途中で修正していたものがあって、Stable がリリースしたタイミングで、同時に更新してみたら、ドラフトが全部消えたという悲しいことがありましたが、まあ大した内容ではありませんし、 Insiders ですし、文句は言えません。

使い方は Insiders リリース時のとあまり変わらないのですが、操作イメージは動画を見た方が分かりやすいかと思います。

また、公式ブログにも詳細情報がありますので、使えない機能等の注意点も併せて参照してみてください。

これまでは別のツールを使ってきましたが、下記で紹介したいと思います。

GitHub を活用する便利なツール

Octotree

https://www.octotree.io/
恐らく定番の中の定番でしょうか。ブラウザの拡張機能で、ディレクトリをツリー表示で参照がかなり楽になります。

github1s

https://github.com/conwnet/github1s

conwnet / github1s

One second to read GitHub code with VS Code.

github1s

One second to read GitHub code with VS Code.

Usage

Just add 1s after github and press Enter in the browser address bar for any repository you want to read.

For example, try it on the VS Code repo:

https://github1s.com/microsoft/vscode

For browser extensions, see Third-party Related Projects.

Or save the following code snippet as a bookmarklet, you can use it to quickly switch between github.com and github1s.com (GitHub markdown doesn't allow js links, so just copy it into a bookmark).

javascript: window.location.href = window.location.href.replace(/github(1s)?.com/, function(match, p1) { return p1 ? 'github.com' : 'github1s.com' })

Develop in the cloud

To edit files, run Docker containers, create pull requests and more, click the "Develop your project on Gitpod" button in the status bar. You can also open the Command Palette (default shortcut Ctrl+Shift+P) and choose GitHub1s: Edit files in Gitpod.

Documentation

Enabling Private

…

View on GitHub

URLのところの github の後に 1s をつけて ENTER キー押下で VS Code（のUI）がブラウザ上で表示されちゃいます！
例：
https://github.com/facebook/react
↓↓↓
https://github1s.com/facebook/react

Gitpod

https://www.gitpod.io/
ローカルへ Clone せず、クラウド上でクローンを行い、ファイルを GitHub 上で直接修正が可能。
過去に .NET Core のリポジトリへプルリクエストを送信したことがあって、これで試してみました。

Joni ✨ ジョニー 🚀

@joni2nja

Trying commit + push #aspnetcore MVC code from #Gitpod. 👍

Gitpod ちょっと試してみた。良さそうやね。

17:21 PM - 06 Sep 2018

Joni ✨ ジョニー 🚀

@joni2nja

VS Code Remote - Containers #dotnetcore サンプル github.com/Microsoft/vsco… を見てみると、タイポ発見。PR送信後、もう１度読んでみると別のタイポに気づき、Gitpodでcommit追加しようとしたら、既にPRマージされた。マージ早っ！ twitter.com/code/status/11…

05:45 AM - 03 May 2019

Visual Studio Code @code
We can't contain our excitement. As of today, you can use a Docker container as your full-time development environment 🤯 🐳 📦 Using the Remote - Containers extension, you can open any folder inside (or mounted into) a container. #remote #containers 👉 https://t.co/GO7YWNsFUH https://t.co/w5XieoHaSU

過去のクラウド上のクローンはダッシュボードで表示されるので、便利です。

修正・更新は VS Code みたいなので特に違和感ありませんでした。

Sourcegraph

https://about.sourcegraph.com/
ブラウザ上でソースコードの検索を中心としたツールです。

Git History

https://githistory.xyz/
ソースコードの変更履歴・差分をアニメーションで表示してくれます。

まとめ

上記の便利なツールで GitHub を使ってきましたが、用途によって使い分けが必要だと思います。個人的は非常にシンプルな検索は GitHub 上で検索 + Octotree、あるいは github1s で済むことが多いのですが、今後より細かく検索・修正したい場合は VS Code で完結できる Remote Repositories を使う場面が多くなりそうです。簡単なプルリクエストを送信したい時もありますので、Remote Repositories で、「検索、一括置換、コミット」するだけで自動的にリモートリポジトリにプッシュされますので、プルリクエストを手軽に送れるようになるかと思います。是非試してみてはいかがでしょうか。

Use System.IO.Pipelines and System.Threading.Channels APIs to Boost Performance

Joni 【ジョニー】 — Sun, 20 Sep 2020 18:03:35 +0000

How to use System.IO.Pipelines and System.Threading.Channels APIs to speed up processing

This post is kind of the continuation of my previous post series: Evaluating “ReadLine using System.IO.Pipelines” Performance in C#.

When I wrote those posts, I was in the need of processing a huge text file (hundreds of thousands of lines), read, parse and transform line by line, and then finally save each of them as a text file. Yes, it will end up a ton of files being created!

I was able to speed up the reading time using System.IO.Pipelines APIs as described in the previous post. The result? 10 minutes faster processing time! 🚀

I could have stopped there. But I didn’t. I recalled the new kids on the block: System.Threading.Channels. See Stephen Toub’s excellent post “An Introduction to System.Threading.Channels” for more information.

An Introduction to System.Threading.Channels | .NET Blog

Think of the reading line by line as the Producer and the line processing part as Consumer. The idea is, to produce as fast as possible using System.IO.Pipelines and consume it— spread the workload concurrently, asynchronously, without blocking like BlockingCollection does.

BlockingCollection involves blocking; there are no task-based APIs to perform work asynchronously. Channels is all about asynchrony; there are no synchronously-blocking APIs — Stephen Toub.

Okay, enough talking. Show me the code!

Base Implementation

Let’s start from the base implementation (i.e., before using System.Threading.Channels APIs); the code is simply adding each line processing method to the Task list and await on all of them.

Note that code on this post is slightly adjusted for benchmarks purpose; eliminating unrelated parts as much as possible.

We can see the task list growing as we process the line.

Task list

Channel Writer (Producer)

Here is the producer part.

To help spot the changes quickly, here is the diff:

Base implementation vs Channel implementation

Should be pretty easy to spot the differences.

Channel Reader (Consumer)

Finally, the consumer part.

Here I defined 3 channel readers and set SingleReader to false (by evaluating ChannelReaderCount == 1). This way, we will have 3 consumers that will process the line concurrently.

This can be observed from the Visual Studio Parallel Stacks window.

Parallel Stacks Window

Tune this value and measure until you get the best performance. Start small, increment the value until you reach to the point where it will give you slower results; it’s the point where you have too many active Task resources, possibly too many context switches.

Benchmarks Result

Okay, let’s see the benchmarks result.

*Wow. Almost 2x faster! * 🚀🚀🚀

Here is the gist version:

That’s the benchmarks result. What about my case? Well, I saved another 10 minutes, so about 20 minutes faster in total!

Source Code

You can find the source code in my GitHub repository, branch: pipelines-and-channels.

Conclusion

If you have huge text files in size containing hundreds of thousands of lines to be processed, consider to use System.IO.Pipelines for reading and parsing the lines, and combine it with System.Threading.Channels APIs to spread the workload concurrently, asynchronously.

Evaluating “ReadLine using System.IO.Pipelines” Performance in C# — Part 2

Joni 【ジョニー】 — Mon, 17 Aug 2020 21:10:37 +0000

Evaluating “ReadLine using System.IO.Pipelines” Performance in C# — Part 2

Read string line by line using System.IO.Pipelines API in C

On part 1 of this series, I concluded:

In terms of speed, it is surprisingly slower than the ordinary ReadLine version given the string length ≤ 80 (perhaps I am doing it wrong? Let me know! I am still learning!). It is starting to shine, getting faster and faster if the string length ≥ 90. (270% 🚀 faster for string length = 1000).

I decided to take a further look and added more patterns to the benchmarks. The new code, instead of blindly using SequenceReader, is a mix of fast ReadOnlySpan and slow SequenceReader; by inspecting ReadOnlySequence.IsSingleSegment property.

The idea is, get a Span once and then pull as many lines as possible out of it before moving to the next segment of the sequence, as also pointed out by a generous Reddit user u/scalablecory, thanks! (apparently a member of the .NET Team?!)

Here is the result:

As you can see, it performs well under every test case, rendering my previous conclusion obsolete!!!

And here is the gist version:

Noticed that this time it has fewer test cases; I reduced some LineCharMultiplier variations, as I don’t think we need it.

You can find the source code in my GitHub repository.

Conclusion

Pipelines versions are better in terms of memory usage (using less memory).
In terms of speed, it is 103% ~ 333% 🚀🚀🚀 faster, depends on the string length.
Less GC pressure (a good thing) for Pipelines versions (Gen 0, Gen 1).
The amount of code to write for the Pipelines version is super longer!

DISCLAIMER: Your mileage may vary. As with all performance work, each of the scenarios chosen for your application should be measured, measured and measured. There is no silver bullet.

Evaluating “ReadLine using System.IO.Pipelines” Performance in C#

Joni 【ジョニー】 — Sun, 16 Aug 2020 16:10:33 +0000

Read string line by line using System.IO.Pipelines API in C

A typical approach for reading a string line by line from a file would probably be using ReadLine APIs. I have heard all good things about System.IO.Pipelines, which was born from the work of the .NET Core team to make Kestrel one of the fastest web servers.

Ben Adams #BlackLivesMatter

@ben_a_adams

Round 19 of @TFBenchmarks is out and ASP.NET Core on Linux racing to the top!

Who would have thought .NET would have been fully OSS and top performer *on Linux* a several years ago? #aspnetcore #dotnet

techempower.com/benchmarks/#se…

23:04 PM - 28 May 2020

168 379

Although it is probably better suited for network socket IO, I was wondering how easy and how does it perform compared to the traditional ReadLine APIs? So I decided to give it a spin by creating simple benchmarks using BenchmarkDotNet as part of my learning journey.

But, for this post, instead of using a file as the source of the stream, I decided to use in-memory, presumably more-stable-for-benchmark MemoryStream. Feel free to modify it to use a file as the stream source and try it yourself.

The code for ReadLine is so dead simple; nothing fancy here.

(My apologies for the possibly misleading method name ReadLineUsingStringReaderAsync; it doesn’t use StringReader class at all).

You will probably spot that unfamiliar C# 9.0 Pattern Combinators is not null; Yes, I’m using the latest (at the time of writing) .NET 5 Preview 7 (5.0.0-preview.7) and the preview version of Visual Studio (Version 16.8.0 Preview 1.0). Don’t blame me, I love bleeding edge stuff!😎

See how is not null is transformed here.

To simplify the processing of a ReadOnlySequence, here I used SequenceReader; taken from the official sample here, modified it slightly to make it follow a similar pattern while (... is not null) as ReadLineUsingStringReaderAsync does.

And finally, here is the result: 40 benchmarks in 15 minutes on my machine.

Here is the gist version:

Legends:

LineNumber : Value of the 'LineNumber' parameter
LineCharMultiplier : Value of the 'LineCharMultiplier' parameter
Mean : Arithmetic mean of all measurements
Error : Half of 99.9% confidence interval
StdDev : Standard deviation of all measurements
Ratio : Mean of the ratio distribution ([Current]/[Baseline])
RatioSD : Standard deviation of the ratio distribution ([Current]/[Baseline])
Gen 0 : GC Generation 0 collects per 1000 operations
Gen 1 : GC Generation 1 collects per 1000 operations
Gen 2 : GC Generation 2 collects per 1000 operations
Allocated : Allocated memory per single operation (managed only, inclusive, 1KB = 1024B)
Code Size : Native code size of the disassembled method(s)
1 ms : 1 Millisecond (0.001 sec)

You can find the source code in my GitHub repository.

Conclusion

Pipelines versions are better in terms of memory usage (using less memory).
In terms of speed, it is surprisingly slower than the ordinary ReadLine version given the string length ≤ 80 (perhaps I am doing it wrong? Let me know! I am still learning!). It is starting to shine, getting faster and faster if the string length ≥ 90. (270% 🚀 faster for string length = 1000).
Less GC pressure (a good thing) for Pipelines versions (Gen 0, Gen 1).
The amount of code to write for the Pipelines version is longer.

[Update] See part 2 of this series for a better version! (Spoiler: faster on every test!)

DISCLAIMER: Your mileage may vary. As with all performance work, each of the scenarios chosen for your application should be measured, measured and measured. There is no silver bullet.

Resources:

【Sysinternals の Process Monitor でトラブルシューティング】謎のネットワークファイル取得失敗

Joni 【ジョニー】 — Fri, 14 Aug 2020 08:01:08 +0000

Sysinternals の Process Monitor を使い、謎のローカルネットワークファイルアクセス失敗のトラブルシューティングをします。

あるWeb アプリケーションの要件としてローカルネットワークに存在するファイルを取得して Web 画面に表示させます。この Web アプリケーションは .NET Core Module で IIS 上で動作します。

Visual Studio で ASP.NET Core アプリケーションの開発時は実は IIS は任意で、Launch Profile を変更することで IIS を使わず通常の .exe のように直接起動できます。.NET Core Debugging with WSL 2 で WSL 2 でもデバッグできるようになります！

Visual Studio Debug Profile

Windows Explorer やコマンドでそれを単独で起動できたり、別のPCにコピーして通常 .exe みたいに簡易に起動できたりしますのですごく便利です。

ローカルネットワークにあるファイルを取得して表示するには色々方法がありますが、その一つは Directory.EnumerateFileSystemEntries です。ローカルで単独 .exe を実行して問題なく ¥¥hogeIP¥directory01 のようにアクセスできた後、ローカルの IIS にデプロイして、問題なく動作したことを確認。

よし、用意されていたテスト環境の AWS EC2 の IIS にデプロイしようぜ！

デプロイ完了し、テストしてみたら、あれ、なぜディレクトリ内のファイルの表示ができてないんだ？

空っぽだぞ！👀

Windows Explorer で ¥¥hogeIP¥directory01 は普通にアクセスできたので、権限まわりが怪しい？😤

エラーログを見てみたら、確かに Directory.EnumerateFileSystemEntries の結果にファイルエントリがなくて、特に Exception もありません。プログラム側で try catch で潰している訳でもありません。権限問題であれば、API の Docs によると SecurityException や UnauthorizedAccessException が出ているはず。それがないのが、謎です。

単独 .exe で実行してみよう。 hoge.exe --urls http://*:5001 のようにポートを指定して起動します。あれ、単独で実行した場合は普通にアクセスできたぞ！ファイル一覧をちゃんと表示されました。

もしかしたら IIS 関連の権限がダメなのかな？

ダメもとで Windows の資格情報マネージャーで IP 認証情報を登録しておくと、どうでしょう？

Windows の資格情報マネージャーで IP 認証情報を登録しておく

うーん、状況変わらず。

試しに IIS のアプリケーションプールアイデンティティアカウントを変更して管理者に設定してみよう。セキュリティ上ではオススメしないけど、とりあえず原因究明が先だ！

管理者に変更してみても同じくアクセスできませんでした・・・IIS に最強の Administrator 権限割り当てやがったぞ！ｗ

タスクマネージャーでちゃんと Administrator になっていることも確認できましたし。

タスクマネージャー

Sysinternals の Process Explorer でも確認しよう！

Process Explorer

Process Explorer で IIS ワーカープロセス (w3wp.exe) の子プロセスで Administrator として実行されていることも確認できましたので、まだアクセスできないのはなぜだ？

こうなりましたら、Sysinternals の Process Monitor でも使ってみますか！

まず、単独 .exe で実行した時のログを取ります。

ネットワークのファイルアクセスOK

はい、Result が SUCCESS で Detail にファイル名もちゃんと出ていますね。

では、IIS で実行した時のログに比較してみましょう。

ネットワークのファイルアクセスエラー

おや、 LOGON FAILURE だと？

その違いは何だ？

待てよ。もしかして、Windows の Session ID が違うから？単独 .exe の場合の Windows Session ID は？

単独 .exe の場合の Windows Session ID

IIS の場合は？

IISアカウントの場合の Windows Session ID

ビンゴ！

そっか、そりゃそうだ。システムとして実行するので Windows Session ID=0 は当たり前。

Windows Session ID の違いで単独 .exe との動作が同じと保証できないもんね。LOGON FAILURE というログも取れましたので、調査報告としての原因はこれで材料が揃いました。

Web アプリケーション側の対応として、ネットワークパスのそれぞれの認証情報をアプリケーション設定で変更可能にしておいて、アクセスする前にアプリケーション側が判断して該当サーバへ認証させます。そうすると、ディレクトリ内のファイルをちゃんと取得できるようになりました。

とりあえず問題解決！

普段なかなか使う場面がないですが、何年ぶりに Process Monitor を使ったかな？

Directory.EnumerateFileSystemEntries はなぜ SecurityException や UnauthorizedAccessException をトリガーしていないのか、謎のままですが🙄。ローカルの Windows 10 で再現してみるとちゃんと例外が出ていますので、 Windows Server だと基本管理者として実行しているから管理者にはそんな例外なんて矛盾しているからトリガーしないとか？🤷‍♂️

まとめ

アプリケーション側にエラーが出力されなくて、正常動作と見なした謎の挙動には、Process Monitor を使ってトラブルシューティングし、ローカルネットワークのファイル取得失敗時のより OS レベルのログを取得することで原因特定と問題解決に繋がりました。🎉🎉🎉🎊🎊🎊

Consider using C# 8 with the .NET Framework

Joni 【ジョニー】 — Thu, 31 Oct 2019 22:01:03 +0000

This post originally appeared on Medium

Consider using C# 8 with the .NET Framework

Yes, you read it right.

According to:

Building C# 8.0 | .NET Blog

… using C# 8.0 is only supported on platforms that implement .NET Standard 2.1.

When we read it, our mental model would naturally say, okay, no support for the .NET Framework. Goodbye. Yes, we know that .NET Core is the future. But what if your superpower stubborn classic thinking customer dictated to use the now-dead-and-stuck (read: mature) .NET Framework technology?

A little good news for you. You can use some of the C# 8.0 features! 🎊

Yes, C# 8 can be used with the .NET Framework and other targets older than .NET Core 3.0/.NET Standard 2.1 in Visual Studio 2019 (or older versions of Visual Studio if you install a Nuget package).

The C# 8/.NET Framework combination is not officially supported by Microsoft. It is, they say, for experts only.

The C# 8/.NET Framework combination is not officially supported by Microsoft. It is, they say, for experts only.

【ふくてん】 Fukuoka.NET Conf 2019の開催＆登壇

Joni 【ジョニー】 — Mon, 14 Oct 2019 12:16:20 +0000

Fukuoka.NET Conf 2019

2019/10/12 にふくてん .NET Conf 2019 の福岡版ローカルイベント無事開催！
🌀強風の中、たくさんの方にご参加いただき、誠にありがとうございました。
イベントページ：
https://fukuten.connpass.com/event/143452/

最初のセッションはなんとScott Hanselman の動画！リアルタイムではなく、日本での .NET Conf 向けに動画を用意してくれました！
長年の大ファンとして凄く嬉しかったです。いつか福岡へ来てくれないかな？？ｗ

ブログまとめ

Microsoft MVP 松村さん通称「MLBお兄さん」と石橋さんのブログまとめはこちら↓↓↓ 是非チェックしてみてください♪

MLBお兄さん投稿：
Fukuoka.NET Conf 2019を開催しました＆登壇をしました
石橋さん投稿：
Fukuoka.NET Conf 2019 開催しました

Twitter まとめはこちら↓
Fukuoka.NET Conf 2019 まとめ

「.NET Core 3.0 で Blazor を使用したフルスタック C# Web アプリの構築」登壇資料

自分の登壇資料はこちら↓

実はスライド作成は前日までブラッシュアップしていたのですが、どんな Blazor スクリーンショットをスライドに載せるか検討していて、ついちょい深いデバッグしていたら、フレームワーク内のスペルミスを発見！そして GitHub 上の Pull Request （プルリク）を送信しました。

Fixes typo in StaticComponentRenderer.cs #14925

jo-ninja posted on Oct 11, 2019

Fixes "reponse" => "response"

View on GitHub

その数日前も、気づいた点を発見し、プルリクを送信しました。

Add missing @ symbols in pages-routing-layouts.md #14984

jo-ninja posted on Oct 06, 2019

Add missing @ symbols in the sample code.

View on GitHub

Fixes invalid parameter name in components.md #14982

jo-ninja posted on Oct 06, 2019

Fixes invalid parameter name in SimpleListView.razor sample code

View on GitHub

Blazor は比較的に新しい技術でもあり、公式ドキュメントはこれからもブラッシュアップされていくと思いますので、皆さんのフィードバックも不可欠ではないでしょうか。

次回のふくてん、皆様のご参加をお待ちしています♪♪ ✨🎉🎊

VS Code リモート開発で .NET Framework の .exe をビルドしてみた

Joni 【ジョニー】 — Thu, 19 Sep 2019 12:31:49 +0000

This post originally appeared on Medium

VS Code リモート開発で .NET Framework の .exe をビルドしてみた

Linux/Mac環境で .NET Framework プロジェクトをビルド可能に～

Visual Studio Code

以前 Twitter で見たのですが、Linux/Mac 環境でフル .NET Framework をターゲットし、ビルドができるらしい。

Muhammad Rehan Saeed

@rehansaeeduk

You can now target and build full .NET Framework on Linux & Mac via Mono with official support. Add this package:

<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" PrivateAssets="All" Version="1.0.0-preview.2" />

#dotnet #dotnetcore

github.com/Microsoft/dotn…

13:11 PM - 02 Jun 2019

66 122

.NET Framework Targeting Pack Nuget Packages (Preview)

できるとのことなので、Linux マシンで普通にビルドしても面白くないので、今回は Visual Studio Code Remote Development（リモート開発）を使って、ビルドして検証してみたいと思います。

まずは VS Code を起動し、 F1 押下、コマンドを打ちます。 rem ad という風に必要最低限の文字列を打つだけで検索結果がヒットしますので、凄く便利です。

必要最低限の文字列を打つことで検索

C# (.NET Core Latest) を選択します。

C# (.NET Core Latest) を選択

Reopen in Container を選択します。

Reopen in Container を選択

そして、開きました。

(高解像度画像を表示)

左側は Windows Terminal で docker events コマンドの結果をリアルタイムで表示しています。右側は VS Code リモート開発の準備ができた画面です。

VS Code の Terminal で dotnet new console を打って新規コンソールアプリケーションを作成します。

dotnet new console
(高解像度画像を表示)

プロジェクトファイルを生成され、デフォルトで .csproj ファイルはこんな感じで作られます。

作成された .csproj ファイル

netcoreapp2.2 を削除して、 net48 に変更します。 net48 は .NET Framework 4.8 の TFM (Target Framework Monikers) です。

dotnet build コマンドでビルドをしてみると、エラーです。

dotnet build でビルド
(高解像度画像を表示)

まあ、エラーは当たり前ですね。Linux 環境で普通に .NET Framework プロジェクトをビルドできない訳ですから。ビルドできるようにするには Microsoft .NET Framework Reference Assemblies が必要です。PackageReference で定義し、再度ビルドしてみます。

PackageReference 追加
(高解像度画像を表示)

お～！(≧▽≦)

宣伝通り、ビルドできましたね！

.exe ファイルちゃんと生成されています！

NuGet サイトで Microsoft.NETFramework.ReferenceAssemblies を覗いてみましょう。

NuGet: Microsoft.NETFramework.ReferenceAssemblies

.NET Framework 4.8 はもちろんのこと、さかのぼって古い .NET Framework 2.0 も対応？！これは凄くないですか！レガシーシステム向けでちゃんと Microsoft がサポートしているということですね。

はい、次！試しに、 dotnet run を実行してみます。

dotnet run エラー
(高解像度画像を表示)

エラーです。これも当然のことですね。

System.ComponentModel.Win32Exception (8): Exec format error
   at Interop.Sys.ForkAndExecProcess(String filename, String[] argv, String[] envp, String cwd, Boolean redirectStdin, Boolean redirectStdout, Boolean redirectStderr, Boolean setUser, UInt32 userId, UInt32 groupId, Int32& lpChildPid, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean shouldThrow)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at Microsoft.DotNet.Cli.Utils.Command.Execute()
   at Microsoft.DotNet.Tools.Run.RunCommand.Start()
   at Microsoft.DotNet.Tools.Run.RunCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Win32Exception 例外発生しましたね。

dotnet run は .NET Core アプリを実行するコマンドですが、生成された .exe ファイルを bash で直接実行したらどうなるでしょう？

bash でバイナリを実行する
(高解像度画像を表示)

当然ながら、 .exe ファイルを Linux 上で直接実行できないよ～！

では、 Windows Explorer を開きます。

Windows Explorer を開く

そこからダブルクリックし、実行します！

(高解像度画像を表示)

おぉ～～！

非常にシンプルなコンソールアプリの検証になりますが、 Linux 環境でビルドした .NET Framework .exe ファイルはちゃんと Windows で実行できたことをこれで証明されましたね！🎉🎉🎉

ここまでは一応検証目標を達成しましたが、今度はマルチターゲットを検証してみたいと思います。

TargetFramework を修正し、複数の .NET Framework を対象にしてビルドしたいと思います。下記のように修正してビルドします。

<TargetFrameworks>net48;netcoreapp2.2</TargetFrameworks>

⚠注：TargetFramework ではなく複数形 TargetFramework s （語尾に「s」）

マルチターゲット
(高解像度画像を表示)

これで .NET Framework 4.8 と .NET Core 2.2 それぞれのバイナリが出来上がりました！👏👏👏

dnSpy で覗いてみましょう。

dnSpy で確認
(高解像度画像を表示)

Linux 環境で .NET Core 2.2 の .dll を実行してみましょう！

bash で実行
(高解像度画像を表示)

Hello World!

実行できましたね。

Windows Explorer を起動します。

Windows Explorer

そこから、アドレスバーで cmd を打って、

cmd

ENTERキー押下！これで Explorer で開いているディレクトリがカレントディレクトリとして設定され cmd を起動されます。

先ほどと同じコマンド dotnet RefAsm.dll を実行します。

Hello World!
(高解像度画像を表示)

Windows でも実行できてますね！

そう、 .NET Core はクロスプラットフォームなのです ✨✨✨

Configure HttpClientFactory to Use Fiddler in .NET Core Microservices-based Docker Containers

Joni 【ジョニー】 — Sat, 15 Jun 2019 15:26:42 +0000

This post originally appeared on Medium

Ever wonder how to configure your Dockerized applications to use Fiddler?

If all of the following conditions are true, then this post might help you. Hopefully.

You are developing microservices-based applications using .NET Core 2.1 or above
You develop using Docker Desktop for Windows (minimum version: 18.03)
You are using HttpClientFactory, an opinionated factory for creating HttpClient instances
You love Fiddler and trying to configure your HttpClient to use Fiddler as the debugging proxy

Let’s say our Docker container application has the following HttpClientFactory setup in Startup.cs:

services.AddHttpClient("mySuperSplendidMarvelousAmazingService")
  .SetHandlerLifetime(TimeSpan.FromMinutes(5))
  .AddPolicyHandler(GetRetryPolicy())
  .AddPolicyHandler(GetCircuitBreakerPolicy());

Note that AddPolicyHandler(...) might be a typical Microservices pattern you can possibly use. See “.NET Microservices: Architecture for Containerized .NET Applications” references.

Now, to configure the HttpClient to “talk” to the Fiddler on the host port 8888 (Fiddler listens on port 8888 by default), we will need to know the host IP address. Thanks to Docker v18.03, we can use the special DNS name host.docker.internal.

Refer to the documentation for more details:

Networking features in Docker Desktop for Windows

So let’s use that special DNS:

services.AddHttpClient("mySuperSplendidMarvelousAmazingService")
  .SetHandlerLifetime(TimeSpan.FromMinutes(5))
// ADD THIS 👇👇👇
  .ConfigurePrimaryHttpMessageHandler(() =>  
  {  
      return new HttpClientHandler  
      {  
          Proxy = new WebProxy("http://host.docker.internal:8888"),  
          UseProxy = true  
      };  
  }) 
// --------- 👆👆👆
  .AddPolicyHandler(GetRetryPolicy())
  .AddPolicyHandler(GetCircuitBreakerPolicy());

That’s it! Now we should be able to inspect the requests/responses in Fiddler.

But wait 🛑⛔🚫!! We don’t want to ship that debugging code to the production, right? Of course not. But sometimes we just want to be able to use it during debugging with a simple flip. Let’s explore some possible solutions:

Use Preprocessor Directive
Use ConditionalAttribute

Use Preprocessor Directive

We accomplish this by using a C# preprocessor directive:

services.AddHttpClient("mySuperSplendidMarvelousAmazingService")
  .SetHandlerLifetime(TimeSpan.FromMinutes(5))
#if DEBUG 😎
  .ConfigurePrimaryHttpMessageHandler(() =>
  {
      return new HttpClientHandler
      {
          Proxy = new WebProxy("http://host.docker.internal:8888"),
          UseProxy = true
      };
  })
#endif
  .AddPolicyHandler(GetRetryPolicy())
  .AddPolicyHandler(GetCircuitBreakerPolicy());

This way, on the production build, it won’t be compiled into Microsoft Intermediate Language (MSIL, or IL for short).

Looks good. Until it’s not. It will fail if we forget to launch Fiddler every time we start our application in the debug mode. So, a better alternative, define and use our own custom symbol, for example: ENABLE_FIDDLER_DEBUG_PROXY:

services.AddHttpClient("mySuperSplendidMarvelousAmazingService")
  .SetHandlerLifetime(TimeSpan.FromMinutes(5))
#if ENABLE_FIDDLER_DEBUG_PROXY 😍
  .ConfigurePrimaryHttpMessageHandler(() =>
  {
      return new HttpClientHandler
      {
          Proxy = new WebProxy("http://host.docker.internal:8888"),
          UseProxy = true
      };
  })
#endif
  .AddPolicyHandler(GetRetryPolicy())
  .AddPolicyHandler(GetCircuitBreakerPolicy());

And define it only when we really need it:

Awesome! 👍

Use ConditionalAttribute

Another possible solution, make use of ConditionalAttribute. Let’s add an extension method:

public static class FiddlerExtensions
{
[Conditional("ENABLE_FIDDLER_DEBUG_PROXY")]
  public static void AddFiddler(this IHttpClientBuilder builder)
  {
    builder.ConfigurePrimaryHttpMessageHandler(() =>
    {
      return new HttpClientHandler
      {
        Proxy = new WebProxy("http://host.docker.internal:8888"),
        UseProxy = true
      };
    });
  }
}

and use it like:

var builder = services.AddHttpClient("mySuperSplendidMarvelousAmazingService")
  .SetHandlerLifetime(TimeSpan.FromMinutes(5))
  .AddPolicyHandler(GetRetryPolicy())
  .AddPolicyHandler(GetCircuitBreakerPolicy());
builder.AddFiddler();

The beauty of this is, the builder.AddFidler() won’t be included in the IL if we don’t have ENABLE_FIDDLER_DEBUG_PROXY defined.

Now, the ugly part, we can’t continue chaining the method calls because it will end up being removed from the IL altogether, thus we are introducing a variable builder here. You can use ILSpy or dnSpy to disassemble and verify this behavior.

Bonus tips!

There is another cool trick for debugging: Debugger.IsAttached

Gets a value that indicates whether a debugger is attached to the process.

if (Debugger.IsAttached) { ... }

This might be useful for some certain scenarios, but I don’t think I will use it for this scenario.

What’s your solution?

Generating Swagger Example Dynamic Request Payload with Swashbuckle

Joni 【ジョニー】 — Tue, 21 May 2019 15:35:53 +0000

This post originally appeared on Medium

New to Swashbuckle? See this official “Get started with Swashbuckle and ASP.NET Core.”

We can generate Swagger example requests with Swashbuckle, see this post.

Let’s say we have the following endpoint:

Ignore the weird implementation, it just a sample. Focus on the method signature.

And here is the Swagger UI page:

Note that this post is using Swashbuckle.AspNetCore version 3.0.

Now suppose we have no choice but to make it accepting dynamic payload — perhaps due to requirement changes from the client. So we change the PostThorRequest request to Jobject request like so:

Now when we run it…

Uh oh…See that, the Example Value is gone!

How to fix this?

Changing the first parameter of SwaggerRequestExample type to Jobject seems to fix it.

and…

Voila! It’s back!

Note that this might be just one way of the possible solutions that work. While it does work, personally, I don’t recommend this kind of dynamic request approach for public facing APIs.

IdentityServer — ConfigurationDbContext でのクロスコンテキストトランザクション

Joni 【ジョニー】 — Tue, 30 Apr 2019 12:36:45 +0000

This post originally appeared on Medium

IdentityServer - ConfigurationDbContext でのクロスコンテキストトランザクション

ConfigurationDbContext を使ってクロスコンテキストトランザクションを処理するには？

IdentityServer とは？

IdentityServer is a free, open source OpenID Connect and OAuth 2.0 framework for ASP.NET Core. Founded and maintained by Dominick Baier and Brock Allen, IdentityServer4 incorporates all the protocol implementations and extensibility points needed to integrate token-based authentication, single-sign-on and API access control in your applications.

詳細はこちらのリンク↓↓↓

Welcome to IdentityServer4 - IdentityServer4 1.0.0 documentation

IdentityServer4 の構成データ (Configuration Data) を EF Core を使って DB に保存することはできます。構成データは「リソース」と「クライアント」を管理します。

EF Core での構成データの詳細についてはこちら↓↓↓

Using EntityFramework Core for configuration and operational data - IdentityServer4 1.0.0 documentation

本題に入ります。

例えば、ビジネスルールのニーズで、アプリケーションの DB Context でデータを追加する必要があり、それと同時にクライアントを追加する必要があるとします。つまり、セットで追加で処理する必要があります。

クライアントのクラスの定義は ConfigurationDbContext に存在します。ctor の定義はこんな感じ：

public ConfigurationDbContext(DbContextOptions<TContext> options, ConfigurationStoreOptions storeOptions)
 : base(options)

この ConfigurationDbContext は IdentityServer のもので、アプリケーションの DB Context と異なるため、それぞれを dbContext.SaveChanges() （あるいは await dbContext.SaveChangesAsync() ）で処理すると、仮に例外が発生した場合に整合性がとれなくなってしまいます。

EF Core でクロスコンテキストトランザクションはサポートされていますので、実現可能です。

Transactions - EF Core

条件としては、

Sharing a DbConnection requires the ability to pass a connection into a context when constructing it.

The easiest way to allow DbConnection to be externally provided, is to stop using the DbContext.OnConfiguring method to configure the context and externally create DbContextOptions and pass them to the context constructor.

そして、

DbContextOptionsBuilder is the API you used in DbContext.OnConfiguring to configure the context, you are now going to use it externally to create DbContextOptions.

だそうです。

簡単そうですね！

サンプルコードはこんな感じで DbContextOptions を生成します。

var options = new DbContextOptionsBuilder<BloggingContext>()
 .UseSqlServer(new SqlConnection(connectionString))
 .Options;

それを ConfigurationDbContext ctor に渡せばいいよね～！！と喜ぶのも束の間・・・

ctor の2番目のパラメータって、 ConfigurationStoreOptions を渡しますよね。DI でこれを気にする必要がなく、やってくれていますので、正しいパラメータはわかりません。。。適当に渡してみてエラーが発生します。デバッグとかで少し時間があればできそうですが、簡単な方法でやりたいです！

そういえば、アプリケーションの DB Context って我々が自由に触れるので、まずそれを使いましょう！ctor は DbContextOptions を渡せるようにします。

こちらのサンプルで話しますと、 context1 は ConfigurationDbContext に例えて、それをそのまま DI からのインスタンスを使い、14行目の：

using (var context2 = new BloggingContext(options))

をこんな感じで context1 の DB コネクションを context2 と共有させます↓

using (var context2 = new ApplicationDbContext(
 new DbContextOptionsBuilder<ApplicationDbContext>()
 .UseSqlServer(context1.Database.GetDbConnection())
 .Options))

はい、これでシンプルで問題解決！

DEV Community: Joni 【ジョニー】

Visual Guide to C# async/await

Synchronous code

Asynchronous code

Visualize using Visual Studio

Synchronous code

Asynchronous code

VS Code の Remote Repositories はいいぞ。その他の便利なツールを比較してみた。

GitHub を活用する便利なツール

Octotree

github1s

conwnet / github1s

One second to read GitHub code with VS Code.

github1s

Usage

Develop in the cloud

Documentation

Enabling Private

Gitpod

Sourcegraph

Git History

まとめ

Use System.IO.Pipelines and System.Threading.Channels APIs to Boost Performance

How to use System.IO.Pipelines and System.Threading.Channels APIs to speed up processing

Base Implementation

Channel Writer (Producer)

Channel Reader (Consumer)

Benchmarks Result

Source Code

Conclusion

Evaluating “ReadLine using System.IO.Pipelines” Performance in C# — Part 2

Evaluating “ReadLine using System.IO.Pipelines” Performance in C# — Part 2

Read string line by line using System.IO.Pipelines API in C

As you can see, it performs well under every test case, rendering my previous conclusion obsolete!!!

Conclusion

Evaluating “ReadLine using System.IO.Pipelines” Performance in C#

Read string line by line using System.IO.Pipelines API in C

Conclusion

Resources:

【Sysinternals の Process Monitor でトラブルシューティング】謎のネットワークファイル取得失敗

Sysinternals の Process Monitor を使い、謎のローカルネットワークファイルアクセス失敗のトラブルシューティングをします。

まとめ

Consider using C# 8 with the .NET Framework

Consider using C# 8 with the .NET Framework

【ふくてん】 Fukuoka.NET Conf 2019の開催＆登壇

Fukuoka.NET Conf 2019

ブログまとめ

「.NET Core 3.0 で Blazor を使用した​フルスタック C# Web アプリ​の構築」登壇資料

Fixes typo in StaticComponentRenderer.cs #14925

Add missing @ symbols in pages-routing-layouts.md #14984

Fixes invalid parameter name in components.md #14982

VS Code リモート開発で .NET Framework の .exe をビルドしてみた

VS Code リモート開発で .NET Framework の .exe をビルドしてみた

Linux/Mac環境で .NET Framework プロジェクトをビルド可能に～

Configure HttpClientFactory to Use Fiddler in .NET Core Microservices-based Docker Containers

Use Preprocessor Directive

Use ConditionalAttribute

Generating Swagger Example Dynamic Request Payload with Swashbuckle

IdentityServer — ConfigurationDbContext でのクロスコンテキストトランザクション

IdentityServer - ConfigurationDbContext でのクロスコンテキストトランザクション

ConfigurationDbContext を使ってクロスコンテキストトランザクションを処理するには？

「.NET Core 3.0 で Blazor を使用したフルスタック C# Web アプリの構築」登壇資料