ソリューションファイル（.sln）はマルチプロジェクトの管理ファイル。

Gitにはhooksがあり、リポジトリに紐付く。通常、1リポジトリ1プロジェクト。

GitのRevertはコミット単位。複数プロジェクトがある場合、それもまとめて差し戻し。
また、プロジェクト間が密結合になりがちで、プロジェクトを分ける意味がなくなるリスクがある。

GitHubのPull Requestはプロジェクトのどこを何の目的で修正するかを明確にし、そしてマージする。

1プロジェクトの場合は影響範囲が明確。

複数プロジェクトがある場合、何のプロジェクトを何の目的で直すかを追跡しづらい。事細かに書いたり、複数プロジェクトであるが故に、専用タグをつけたりするのは面倒。
そもそもシステマチックでないし、間違いの元。
GitHub Actionsも面倒になる。
わざわざ除外パスをメンテしていかないとダメ。

Microsoftのリポジトリですら、割とGitHub Actionsの定義がない。
CI/CDのパイプラインは別で管理しようと思えばwebhooksを使えばできるはずだが、結構、面倒だった。特にネットワーク周りが。

しかし、単体テストより後の結合テストやシステムテストの自動化を考えた場合、このあたりを管理するのは別がいいのかな？
Jenkinsのジョブ連携を使うとか…。
Microsoftはシフトレフトの手法らしいから、結合テストやシステムテストは軽めなものを常時回しているのかもしれない。

とりあえず、.NET Aspire込みの管理を考えた。

+Solution and Project root
 +Tests　＜ビルド対象外指定＞
  +UnitTest
   -～.csproj
  +ComponentTest
   -～.csproj
 +Extensions　＜ビルド対象外指定＞
  +Aspire用プロジェクト
   -～.csproj
 -.git
 -.github
 -～.csproj
 -～.sln

プロジェクトルートのcsprojにTestsとExtensionsの除外設定を追加して使う。
レベルを下げてしまえば、以降、保守が入っても、機能的に関係がないプロジェクトの混入によるカオスは防げる…はず。
プログラム本体と単体テストコードの依存関係もバッチリ。ここを別リポジトリ管理にすると、テストコードの直し忘れが頻発するのは火を見るより明らか。

っていうか、Aspire。
Extensionの為だけに1プロジェクト使うってどういうこと。
Container Apps環境にAspireが加わっていたことだし、これからは.NET=マルチプロジェクト限定っぽい。

Visual Studio上では、Aspireの追加は「.NETオーケストレーションの追加」でできる。
AppHostは独立しており、依存関係がないから捨てることができる。
Extensionだけ入れるようにすれば良い感じになるはず。

Visual Studioのソリューションファイルは異なる要素を入れ込まれる可能性さえ消してしまえば、依存プロジェクトを適切に管理できる点でメリットがある。
一方で、何でも突っ込みたがるお行儀の悪い人たちを将来的に排除するためには、入り込めないようにしておかないとカオスになる。

適切な機能設計ができない人が多すぎて、ソリューションファイルは基本的にカオスが多い。
日本だけかもしれないが。