長年にわたり、.sln ファイルは .NET ソリューションの基盤として機能してきた。開発者は通常これを手動で編集せず、ビルドが通れば問題ないと考え、Git にコミットするだけだった。

しかし、この状況は変化している。.NET SDK 9.0.200 以降でプレビューとして導入された .slnx フォーマットは、.NET 10 から新規プロジェクトのデフォルトとなり、単なる拡張子の変更ではなく、「ソリューション」そのものの再定義を意味する。

.sln の限界

.sln は Windows と Visual Studio が中心だった時代に設計され、現代の開発要件には適合しなくなっている：

• 人間が読めない形式：GUID や内部識別子が混在し、可読性が低い。
• バージョン管理との相性が悪い：Visual Studio のバージョンアップだけで無関係な差分が発生し、マージコンフリクトが頻発。
• IDE 依存が強い：他のツール（CLI や CI スクリプトなど）からの操作が困難。
• クロスプラットフォーム対応が不十分：COM コンポーネントに依存しており、Linux/macOS 上での自動生成・編集が難しい。

.slnx の設計思想

.slnx は、現代的な開発ワークフローに最適化された新しいソリューション記述形式である：

• XML ベースで可読性が高い：構造が明確で、既存の .csproj と同様の形式。
• 宣言的記述：「どのプロジェクトが含まれるか」のみを定義し、IDE 固有の設定を含まない。
• GUID 不要：プロジェクト参照はパスベースで記述される。
• CLI とツール中立：dotnet CLI、Visual Studio、VS Code、および各種 CI 環境でネイティブサポート。

典型的な .slnx ファイルの例：

<Project Sdk="Microsoft.Build.NoTargets">
  <ItemGroup>
    <ProjectReference Include="src/WebApp/WebApp.csproj" />
    <ProjectReference Include="src/Core/Core.csproj" />
  </ItemGroup>
</Project>

実際のメリット

Git コラボレーションの改善
.sln では Visual Studio の更新ごとに不要な差分が発生していたが、.slnx ではプロジェクト追加時に1行の変更のみで済み、レビューが容易になる。

CI/CD の信頼性向上
dotnet build や dotnet test が直接 .slnx を認識するため、スクリプトによる動的生成や条件付きビルドが安全に実現可能。

エコシステムの開放性
dotnet sln add/remove コマンド、VS Code C# 拡張、さらには AI コーディングアシスタントもプロジェクト構造を正確に理解できるようになる。

移行戦略

マイクロソフトは段階的な移行を推奨しており、以下のような手段が提供されている：

• 並行利用可能：.sln と .slnx を同一リポジトリで共存可能。
• 簡単な変換：

  dotnet new slnx -n MySolution
  dotnet sln add src/**/*.csproj

• 既存資産との互換性：.slnf ファイルは .slnx を指すように更新するだけで動作可能。

必要な環境と注意点

• Visual Studio 2022 バージョン 17.13 以上
• .NET SDK 9.0.200 以上
• Linux/macOS でも dotnet CLI が完全対応
• 内部的には MSBuild プロジェクトファイルとして処理され、新規文法ではない

.slnx は、SDK スタイルの .csproj や global.json とともに、「宣言的で自動化に強い .NET 開発基盤」を構成する重要なピースとなる。