ココの続きになるかと思いますが、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サーバーに変更されるようです。今後、機会があったら試してみたいですね。)