ココの続きになるかと思いますが、WSL開発環境、大方、出来上がりました。...と言っても、単に、SDK入れて、リモートデバッグ設定して、開発で、こういう風にWSLを使えばエエんジャないか？という系の話ですが。
※ ちなみに、ASP.NET Coreのリモートデバッグについては調査中。
...私、以前、一年以上前になりますが、.NET Core化に着手した当時は、
Docker（Visual Studio Tools for Docker）推しで、Open Paas系にも期待をしていましたが、ココのトコロ、互換レイヤと言う事で「Windowsと同一IPアドレスで、ローカファイルを使用可能」なWSL推しになっています。
何故か？...と言えば、やっぱ、
「Docker、Open Paasは環境として、別サーバになるので、CI/CD等には適合しますが、単体・結合テストで使用する環境やテスト手法としては不適切」
のように思うからです。という話は、
以前、書いた通りです。
...で、具体的なプラクティスとしては、「Windows上のVisual Studioで開発して、WSL上でテストする。」です。非常にシンプルですね。
テストの際は、Windows上のVisual StudioからWSLへ、リモートデバッグ的に接続します。Visual Studioからのリモートデバッグは、C/C++開発と、.NET Core開発で使用できます。
なお、以下の様な仕組みで動作しているらしいので、SSHでの接続が可能であればリモートデバッグが可能なので、WSLに限らず、WSL2や、素のLinux VM、Dockerや、他のOpen PaaSでもリモートデバッグが可能と思います。
＜Windows＞
Visual Studio → DebugAdapterHost → PuTTY
↓↓↓（SSH）↑↑↑
＜Linux＞
openssh-server → vsdbg → dotnet (XXXX.dll)
.NET Coreのリモートデバッグの仕組み
ここで、DebugAdapterHostと言う文字列が見えますが、調べると、M某社、Debug Adapter Protocol と Visual Studio Debug Adapter Hostを開発して、Windows（Visual Studio）からだけでなく、macOS（Visual Studio Code）からもLinuxとリモートデバッグできるようにしてるっポイですね。
デスクトップとしてWindowsを使用し続けているのは、やはり、デスクトップOSとしてはWindows（若しくはmacOS）が優秀だからなんでしょう。LinuxをデスクトップOSとして使うのは、実際に使ってみても、
この辺りを見ても、チョット難しい印象ですね。
しかし、クラウドで動作するサービスを運用する土台としてはLinuxが優秀なんでしょうね。その折衷案として、Windows、若しくはMac OS上のIDEから、Linuxへ接続してのリモートデバッグ。...が、今後、一般的になって行くんじゃないか？と考えています。
余談： （´-`）.｡oO（Visual Studio Codeでは、VS Code Remote Developmentと言う拡張がリリースされており、他の、様々な言語 ＆ 接続先（Remote SSH、WSL、Containers）でのリモートデバッグが可能であるようです。）
（´-`）.｡oO（そう言えば一昔前、Open PaaSな人がリモートデバッグ設定の記事を書いていましたが、ナルホド、コレをしてたのか！という感じですね。でも、サーバーが対象となると、ターゲットになる人、余り居なかったんじゃないでしょうか？昨今は、WSLやIoTデバイスなどへの開発時のリモートデバッグ接続の需要が高まって来ている感じはします。）
（´-`）.｡oO（ちなみにWSL2はHyper-V上で動作するらしいですが、UI / UXはWSLを踏襲しており、WSL2の新しいバージョンでは、WSLと同様に " localhost:ポート番号 " で通信ができるようです。また、ローカルファイルを共有する仕組みは、DrvFsから9Pサーバーに変更されるようです。今後、機会があったら試してみたいですね。）
Open COBOL Solution WG
WSL開発環境、大方、出来上がった感。最新の開発環境についての考察 ①
