C# のファイルベースの実行 in .NET 10

Tim Corey

13m 36s

C# は常にコードを実行するためにプロジェクトファイルを必要としていました。 最も単純な"Hello World"でも、Program.cs、およびビルドステップが必要で、実行する前にそれらを経る必要がありました。 ただし、.NET 10 ではそれが変わります。 今では単一の.csファイルを書いて直接実行することができます。PythonスクリプトやNode.jsファイルを実行するのと同じ方法です。

彼のビデオ"ファイルベースの C# 実行 in .NET 10"では、Tim Corey がこの機能のすべての側面を説明します：スタンドアロンのファイルを実行し、コマンドライン引数を渡し、NuGet パッケージをインラインで追加し、ネイティブライカブルに公開し、単一ファイルフォーマットの範囲を超えるとプロジェクトに変換するプロセス。 コンソールアプリでクイックスクリプトやプロトタイプを使用している場合、この変更はワークフローを大幅に変更します。

単一の C# ファイルを実行する

（[0:40 - 1:48]）Tim は VS Code を使用して空のフォルダーから始めます。 ソリューションもプロジェクトファイルもありません、ボイラープレートもありません。 彼はdemo.csという単一ファイルを作成し、1行のコードを書きます。

Console.WriteLine("Hello World");

Console.WriteLine("Hello World");

それを実行するには：

dotnet run file demo.cs

dotnet run file demo.cs

それがすべてのワークフローです。 objフォルダーも作成されません。 メンタルモデルは伝統的な C# 開発というよりはスクリプトに近く、ファイルを作成して実行し、出力を見るものです。

Tim は Python や JavaScript に直接比較し、これらの言語が常に単一ファイル実行をデフォルトとして使ってきたことを示しています。 .NET 10 は、C# をこの領域に引き込むことで、C# を最初に魅力的にする型安全性とパフォーマンスを保持します。

コマンドライン引数と暗黙の使用

[1:48 - 3:26] Program.csと同じように動作します。 Tim はファイルを変更して名前引数を受け付けるようにします：

Console.WriteLine($"Hello {args[0]}");

Console.WriteLine($"Hello {args[0]}");

引数を指定して実行する：

dotnet run file demo.cs Tim

dotnet run file demo.cs Tim

これが"Hello Tim"と表示されます。 Timは、ファイルベースの実行がデフォルトで暗黙的なusingを含むため、using System;ステートメントなしで動作することを指摘しています。 これは C# 9 で導入されたトップレベルステートメントと同じ動作で、現在はスタンドアロンファイルに拡張されています。

Microsoftが追求してきたより広いパターンは、C#から徐々にセレモニーを削除することであり、グローバルusing、トップレベルステートメント、そして現在では単独の.csファイルが、以前はPythonやbashスクリプトを必要としていた迅速なタスクにC#を使用可能にするための手段です。

ユーザー入力の追加

（[3:26 - 5:43]）Tim は引数のアプローチを対話型入力で置き換え、ファイルベースの実行が コンソールアプリケーション パターンのフルレンジをサポートしていることを示します：

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

これは入力を求め、応答を読み取り、挨拶を表示します。 標準的な入出力はフルプロジェクトと同じように機能します。

Timが指摘する唯一の制限: このモードは単一ファイル専用で、2つの.csファイルが互いに参照し合うことはできません。 コードのサイズが拡大し、複数のファイルが必要になった場合は、プロジェクトに変換してください（ビデオの後半で説明されています）。

NuGet パッケージの導入

（[5:43 - 7:49]）ここで単一ファイルアプローチはスクリプトに対して真に有用です。 ファイルの先頭に.csファイル内に直接NuGetパッケージを参照することができます。

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

#r "nuget:..."構文は、コンパイル前に指定されたパッケージをダウンロードし参照するようにランタイムに指示します。 Tim は Spectre.Console を使用して出力の色を変え、挨拶のテキストを赤にします。

コマンドなしの.csprojもなく、リストアステップもありません。パッケージ参照はソースファイル自体にあります。 HTTP クライアント、JSON シリアライザー、フォーマットライブラリを必要とするスクリプトの場合、単一の依存関係を引き込むためにプロジェクトを作成するオーバーヘッドを排除します。

ネイティブ実行可能ファイルへの公開

（[7:49 - 8:59]）ファイルベースのスクリプトをスタンドアロンバイナリとして配布したいときは、publish コマンドが処理します：

dotnet publish file demo.cs

dotnet publish file demo.cs

これはartifactsフォルダーに実行可能ファイルを生成します。 コンパイルされたバイナリには、ターゲットマシンで .NET SDK を必要とせずに実行するために必要なすべてが含まれています。Tim は、ファイルベースのビルドがデフォルトでネイティブ AOT を使用することを指摘し、これにより、出力は高速な起動時間の単一の自己完結したバイナリになります。

ある特定のライブラリと互換性問題を引き起こす場合、ファイルの上部にプロパティディレクティブを追加して、Native AOTを無効にすることができます（#rがパッケージに対して機能するのと同様です）。 しかし、ほとんどのスクリプトユースケースでは、AOT が適切なデフォルトです。

フルプロジェクトへの変換

（[8:59 - 10:45]）スクリプトが単一ファイル形式から範囲を超えたときの脱出口は convert コマンドです：

dotnet project convert file demo.cs

dotnet project convert file demo.cs

これにより、.csprojファイルが生成され、NuGet パッケージ参照が#rディレクティブから取り込まれ、標準的なプロジェクト構造にコードが移動されます。 そこからは、複数のファイルを追加したり、ビルド設定を構成したり、完全な .NET プロジェクトシステムを使用することができます。

Tim はこれを自然な進化として捉えており、迅速な試験のために単一ファイルから始め、範囲が拡大する場合はプロジェクトに昇進させる際に、何も書き直さずに行うことができると示しています。 <PackageReference>エントリーにきれいに変換されます。

ネイティブ AOT とプラットフォームの注記

（[10:45 - 12:42]）デフォルトで、ファイルベースの実行はネイティブ AOT でコンパイルされ、可能な限り高速な起動を提供します。 Tim は、これは CLI ツールやコールドスタート性能が問題となるスクリプトに理想的であると指摘しています。 AOT と互換性のないライブラリがある場合、ファイルレベルのプロパティで機能を無効化することができます。

LinuxおよびmacOSでは、dotnet run fileプレフィックスを入力せずに直接実行可能です。 これにより、C# は Bash、Python、および Ruby と並んでフルにスクリプト領域に入ります。

まとめ: C# をスクリプト言語として使用する

（[12:42 - 13:05]）Tim が最も影響力があると強調する機能は、小規模なタスクにはプロジェクトオーバーヘッドを排除することです。 コンソールアプリは常に簡単な実験や自動化スクリプト、一時的なツールの定番でした。 ファイルベースの実行は、必要な以上にこれらを重く感じさせた儀式を取り除きつつ、C# を選ぶ理由であるあらゆる利点（型安全性、パフォーマンス、NuGet エコシステム）を保持します。

結論

[13:05 - 13:36] まとめると、.NET 10のファイルベースの実行により、単一のdotnet project convert fileでフルプロジェクトに変換することができます。 デフォルトでネイティブ AOT がオンであり、Linux / macOS ユーザーはシェルレベルで実行するためのハッシュバングサポートを持っています。

現在コンソールアプリを使用してプロトタイピングや自動化を行っているすべてのものに対して、これは軽量の代替手段として試す価値があります。

例のヒント: NuGet パッケージをテストするためや、API 呼び出しをデバッグするためだけにコンソールアプリを作っているなら、代わりにファイルベース実行を試してみてください。 dotnet run fileで実行します。 完了したら、そのファイルを削除します。プロジェクトクリーンアップは不要です。

彼の YouTube チャンネルで、ビデオの全編を視聴し、最新の C# 開発ワークフローについてさらに洞察を得てください。