.NETの新ジャンル：NuGet-Free Single File C#コーディングの時代
C#がスクリプト言語のように軽くなるのではなく、スクリプト言語が羨むほど速くなるということです。 はじめに .NET 10で導入されたdotnet run file.cs——いわゆる** file-based app**——は、.csprojファイルなしで単一の.csファイルだけでC#コードを実行できる機能です。しかし、現在この機能の実行速度は初回実行基準でWindowsで約1.5秒、WSL2で約0.8秒レベルです。Pythonのpython script.pyが50ms前後であることと比較すると、まだ「スクリプティング」と呼ぶには物足りない水準です。 しかし、現在.NETエコシステムで同時に進行中の2つの大きな変化が、この状況を根本的に変える可能性があります： dotnet run file.csのビルド最適化 — MSBuildをバイパスしてRoslynを直接呼び出す戦略 Runtime Async (async2) — async/awaitをランタイムレベルで処理し、ステートマシンのオーバーヘッドを除去 この2つが組み合わさると、** NuGetパッケージなしでBCLだけで書くシングルファイルC#プログラム** が独立したコーディングジャンルとして確立される可能性があります。この記事では、その技術的基盤と将来像を描きます。 File-Based Appの現状：MSBuildというボトルネック 本質：.csproj + .cs = 1つの.cs File-based appはC#スクリプト（.csx）とは根本的に異なります。.csxは別のスクリプトホストがランタイムで解釈しますが、file-based appは** コンパイル時に仮想.csprojに変換** されて正規のビルドパイプラインを通ります。出力は通常のプロジェクトと同一のmanaged DLLです。 // これらのディレクティブが.csprojの内容になる #:package System.CommandLine@2.0.0 // ここからが実際のコード Console.WriteLine("Hello, file-based app!"); 問題：MSBuildの重さ dotnet run hello.csを実行すると内部で起こること： ステップ 所要時間（概算） 説明 CLIロード ~200ms .NETランタイムJIT、CLIコマンドディスパッチ MSBuildエンジンロード ~200ms ビルドエンジン初期化 SDK targets評価 ~300ms 数百の.props/.targetsファイルの順次評価 NuGet restore ~100ms+ パッケージ依存性解決（キャッシュ済みの場合） Roslynコンパイル ~200ms 実際のC# → IL変換 実行 ~50ms 結果のDLL実行 合計約1.5秒 のうち実際の「コンパイル＋実行」は約250msに過ぎません。残りはすべてMSBuild関連のオーバーヘッドです。 ...