C#を使用したアプリケーション開発において、コマンドラインインターフェース（CLI）の活用は開発効率を劇的に向上させる重要な要素です。
その中でもdotnet runコマンドは、ソースコードのコンパイルから実行までをシームレスに行うための中心的な役割を担っています。
モダンな.NET開発では、Visual Studioのような重厚な統合開発環境だけでなく、VS Codeやターミナルを駆使した軽量な開発スタイルが一般的になっています。
本記事では、日常的な開発で欠かせないdotnet runコマンドの基本から、実務で役立つ応用オプション、さらには最新のホットリロード機能までを詳しく解説します。
dotnet run コマンドの本質と基本操作
dotnet runは、プロジェクトのソースコードをビルドし、生成された実行ファイルを即座に起動するためのコマンドです。
このコマンドの最大の特徴は、コンパイルと実行という2つの工程を一つの命令で完結させられる点にあります。
通常、C#プログラムを実行するには「ビルド（dotnet build）」と「実行（dotnet exec等）」の手順が必要ですが、これを自動化してくれます。
基本的な使用方法は非常にシンプルで、プロジェクトファイル（.csproj）が存在するディレクトリで以下のコマンドを入力するだけです。
dotnet runこのコマンドを実行すると、.NET CLIはカレントディレクトリ内のプロジェクトファイルを自動的に探索します。
プロジェクトが発見されると、依存関係の復元（restore）とビルドが行われ、最終的にアプリケーションが起動します。
以下に、標準的なコンソールアプリケーションを実行した際の出力例を示します。
// Program.cs の内容
using System;
Console.WriteLine("Hello, .NET 2026!");Hello, .NET 2026!暗黙的なリストアとビルドの挙動
dotnet runを実行する際、内部では自動的にdotnet restoreとdotnet buildが呼び出されています。
これにより、ライブラリの追加直後であっても、個別にビルドコマンドを打つ手間が省けるというメリットがあります。
ただし、大規模なプロジェクトでは毎回ビルドチェックが走ることで、起動までに数秒の待ち時間が発生する場合があります。
開発サイクルを高速化したい場合は、後述するオプションを活用してビルドプロセスをスキップすることも可能です。
実務で役立つ主要なオプション指定
dotnet runには、開発環境や実行時の振る舞いを制御するための豊富なオプションが用意されています。
これらのオプションを使いこなすことで、デバッグ効率や環境の切り替えがスムーズになります。
プロジェクトファイルの指定（–project）
複数のプロジェクトが混在するソリューション環境では、実行したいプロジェクトを明示的に指定する必要があります。
--project（または -p）オプションを使用することで、ディレクトリを移動することなく特定のプロジェクトを起動できます。
dotnet run --project ./MyAwesomeApp/MyAwesomeApp.csprojこの指定により、カレントディレクトリがルートであっても特定のサブプロジェクトを正確に実行可能です。
構成の切り替え（–configuration）
デフォルトではDebug構成で実行されますが、リリース時の挙動を確認したい場合はRelease構成を指定します。
--configuration（または -c）オプションを使用することで、最適化の有無を切り替えられます。
dotnet run -c Releaseパフォーマンス計測を行う際などは、必ずRelease構成で実行するように習慣づけましょう。
フレームワークの指定（–framework）
マルチターゲットを指定しているプロジェクトの場合、どのターゲットフレームワークで実行するかを選択できます。
例えば、.NET 8と.NET 9の両方をサポートしているライブラリの動作検証などで利用します。
dotnet run --framework net8.0よく使われるオプション一覧
以下に、頻繁に利用されるオプションをまとめました。
| オプション | 説明 |
|---|---|
--no-build | ビルドをスキップして実行のみを行う。起動が速くなる。 |
--no-restore | 依存関係の復元をスキップする。 |
--launch-profile | launchSettings.jsonに定義された特定のプロファイルを使用する。 |
--verbosity | ログの出力レベル（quiet, minimal, normal, detailed, diagnostic）を制御する。 |
アプリケーションへの引数受け渡し
開発中のアプリケーションにコマンドライン引数を渡したい場合、dotnet run自体のオプションと区別する必要があります。
これを行うには、ダブルダッシュ（–）セパレーターを使用します。
セパレーター以降に記述された内容は、すべて実行されるアプリケーションのargsとして渡されます。
dotnet run -- --input data.txt --mode fastこの例では、--inputや--modeはdotnet runの命令ではなく、C#プログラム内のMainメソッドに渡される引数となります。
引数を受け取るC#側のコード例を以下に示します。
foreach (var arg in args)
{
Console.WriteLine($"引数を受信しました: {arg}");
}引数を受信しました: --input
引数を受信しました: data.txt
引数を受信しました: --mode
引数を受信しました: fastセパレーターを忘れると、.NET CLI自体が知らないオプションとしてエラーを出すため注意が必要です。
launchSettings.json による実行環境の管理
ASP.NET CoreなどのWeb開発や複雑なアプリ開発では、環境変数やポート番号の管理が欠かせません。
Properties/launchSettings.jsonファイルを使用すると、これらの設定をプロファイルとして保存できます。
dotnet runはデフォルトでこのファイルを参照し、適切な設定を適用してくれます。
{
"profiles": {
"Development": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:5001;http://localhost:5000",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"MY_CUSTOM_KEY": "Value2026"
}
},
"Staging": {
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Staging"
}
}
}
}特定の環境（例えばStaging環境）の挙動を確認したい場合は、以下のように実行します。
dotnet run --launch-profile Stagingこれにより、ソースコードを書き換えることなく実行環境を動的に切り替えることが可能になります。
dotnet watch を活用したホットリロード開発
現代のC#開発において、dotnet runの進化形とも言えるのがdotnet watchコマンドです。
これはファイルの変更を監視し、コードを書き換えるたびに自動的にアプリケーションを再実行、またはホットリロードする機能です。
特にUI開発やAPIの微調整を行っている際、いちいちコマンドを打ち直す手間がなくなります。
dotnet watch runこのコマンドを実行した状態でソースコードを保存すると、即座に修正が反映されます。
ホットリロードが適用可能な修正（メソッド内のロジック変更など）であれば、アプリケーションを再起動せずに実行状態を維持したまま変更が適用されます。
大幅な構造変更の場合は自動的に再ビルドと再起動が行われるため、常に最新の状態を保ちながら開発に集中できます。
開発効率を最大化したいのであれば、単なるdotnet runよりもdotnet watch runを常用することをお勧めします。
パフォーマンス最適化：–no-build の活用術
開発が大規模になり、プロジェクトのビルド時間が無視できなくなってきた場合に有効なテクニックがあります。
それは、--no-buildオプションを利用することです。
コードの変更がないことがわかっている場合や、既にdotnet buildを終えている状態で連続して実行したい場合に役立ちます。
dotnet run --no-buildこのオプションを付けることで、.NET CLIはソースコードの変更チェックや再コンパイルを一切行いません。
結果として、アプリケーションの起動時間をコンマ数秒レベルまで短縮できます。
自動テストスクリプトや、特定の条件下での連続実行テストなどで非常に重宝するテクニックです。
トラブルシューティングとよくあるエラー
dotnet runを使用している際、稀に予期せぬエラーに遭遇することがあります。
代表的なエラーとその対処法を理解しておくことで、開発の手を止める時間を最小限に抑えられます。
プロジェクトが見つからない場合
「Couldn’t find a project to run.」というエラーが出た場合、カレントディレクトリに.csprojが存在しない可能性があります。
この場合は、ディレクトリを移動するか、前述した--projectオプションでパスを正しく指定してください。
依存関係の不整合
NuGetパッケージの更新直後などに実行に失敗する場合は、一度キャッシュをクリアしてから実行すると解決することが多いです。
dotnet clean
dotnet runこれでも解決しない場合は、binおよびobjフォルダを手動で削除してからの再実行を試みてください。
dotnet exec との違いを知る
上級者向けの知識として、dotnet runとdotnet execの違いについても触れておきます。
dotnet runは「プロジェクトファイル」を対象としてビルドから行いますが、dotnet execは「ビルド済みのDLLファイル」を直接実行します。
本番環境（コンテナ環境など）では、SDKが含まれない実行用ランタイムのみがインストールされていることが一般的です。
そのような環境ではdotnet runは動作せず、コンパイル済みのDLLを起動する形式になります。
開発時は利便性の高いdotnet runを使い、実行環境の最適化を考える際はDLLの直接実行を意識すると良いでしょう。
まとめ
dotnet runコマンドは、単なる実行命令以上の機能を備えた強力なツールです。
基本的な実行から、引数の受け渡し、環境プロファイルの切り替え、そしてホットリロードによる高速な開発サイクルまで、その活用範囲は多岐にわたります。
特に--セパレーターによる引数指定や、dotnet watchによる自動化は、日々のコーディングのストレスを大幅に軽減してくれます。
本記事で紹介した各種オプションを場面に応じて使い分けることで、より洗練されたC#開発ワークフローを構築してください。
最新の.NET環境ではCLIの進化が続いており、これらのコマンドをマスターしておくことは、将来にわたって長く役立つ技術資産となるはずです。