すべての開発者が知るべき5つ for .NET CLIコマンド

dotnet --infoで環境を確認する

[0:31 - 1:25] プロジェクトコマンドを実行する前に、Timは開発環境を確認し始めます。 dotnet --infoはさらに進みます：

dotnet --info

dotnet --info

これにより、マシンにインストールされているすべてのSDKとランタイムバージョンと、オペレーティングシステムの詳細、アクティブなアーキテクチャが出力されます。 Timは.NET 10でこれをデモンストレーションしますが、コマンドはすべてのバージョンで同じように動作します。 インストールされているものを知ることは、バージョンの不一致をデバッグしたり、CIサーバーがローカル設定を反映していることを確認する際に特に役立ちます。

コマンド1：dotnet build

[2:16 - 3:44] 最初のコマンドは、プロジェクトを起動せずにコンパイルします。

dotnet build

dotnet build

プロジェクトディレクトリからこれを実行すると、binフォルダの下にコンパイルされた出力が生成されます。 Timはコンパイルが実行とは別の独立したステップであることを指摘します。 リポジトリにプッシュする前やビルドサーバーに引き渡す前にコードが正常にコンパイルされるのを確認したいときに、この分離が重要です。

.NET SDKは、ビルドプロセス中に依存解決を処理し、欠落しているNuGetパッケージを取得し、すべての参照アセンブリが存在することを確認します。 この段階で何かが失敗すると、エラーメッセージは、参照の欠落、構文エラー、ターゲットフレームワークの不一致であろうと、問題の所在を直接指し示します。 アプリケーションを実行する前にこれらの問題を見つけることは、全体の開発サイクルで時間を節約します。

コマンド2：dotnet run

[3:44 - 5:42] runは次のステップを踏み出し、アプリケーションを起動します：

dotnet run

dotnet run

これにより、必要であればプロジェクトをコンパイルし、その後に結果の出力を実行します。 コンソールアプリケーションの場合、それはターミナルで実行されます。 Webプロジェクトの場合、組み込みのKestrelサーバーが起動し、アプリがローカルURLで利用可能になります。

TimはWebアプリケーションでこれを示し、すべてが正しく読み込まれることを確認するためにブラウザで実行中のサイトをナビゲートします。 runがライブでインタラクティブな結果を生成することです。 アクティブな開発中には、変更をテストしてその影響を確認するために最も頻繁に使用するコマンドです。

コマンド3：dotnet watch

[5:42 - 7:06] アプリケーションを停止し、変更を加え、再起動するのはすぐに面倒になります。 watchコマンドはそのサイクルを排除します：

dotnet watch

dotnet watch

これは実行プロセスをファイル監視モードでラップします。 任意のソースファイルに変更を保存すると、CLIはその変更を検出し、自動的に再コンパイルしてアプリケーションを更新します。 ASP.NET Coreを使用して構築されたWebアプリケーションの場合、Razorファイル、CSS、C#コードの変更が手動での再起動なしにブラウザに現れます。

Timはページを編集し、保存し、変更が即座に反映される様子を示します。 この緊密なフィードバックループは、UI作業中に小さな調整が頻繁に発生する際に価値があります。 停止-編集-再構築-起動を繰り返すのではなく、コードに集中し、ツールが他の部分を処理します。

コマンド4：dotnet clean

[7:06 - 7:56] ビルドアーティファクトは時間とともにcleanコマンドはこれに対処します：

dotnet clean

dotnet clean

これを実行すると、出力ディレクトリの内容が削除され、その後のビルドが最初から始まります。 Timはこれをトラブルシューティングツールとして位置付けていますが、毎回の変更後に実行することはありません。 プロジェクトが予期しない動作をしており、キャッシュされた出力が原因と疑われる場合、buildを行うことで、本当に新しいコンパイルを使用していることを確認できます。

バージョン管理でブランチを切り替えるとき、依存関係を新しいメジャーバージョンにアップグレードするとき、または明確な原因がなく断続的なビルド警告が現れるときに特に有用な習慣です。

コマンド5：dotnet publish

[7:56 - 9:01] 最後のコマンドは、開発とデプロイメントの間のギャップを埋めます。

dotnet publish

dotnet publish

publishはデプロイメント準備済みのパッケージを作成します。 コンパイル済みアセンブリ、設定ファイル、静的アセット、必要なランタイムコンポーネントは、サーバーに直接コピーできるpublishフォルダに配置されます。

publishの区別は、一部の開発者を驚かせることがあります。 build出力には、デバッグ記号や開発中に役立つ参照が含まれていますが、本番環境では不要（時には望ましくない）です。 配信ではこれらの追加機能を削除し、ターゲット環境用に出力を整理します。 Dockerへのデプロイやクラウドホストへのアップロードの際には、公開された出力が最終イメージやリリースパッケージに属します。

締めくくり：5つのコマンド、1つのワークフロー

[9:01 - 9:15] Timは5つのコマンドをすべて一緒にリストし、閉めます：dotnet publish。 一連のセットとして取られて、コンパイルからデプロイメントまで、コアの開発ループをカバーします。 それぞれが特定の目的を果たし、各々に頼れる時を知ることは、IDEボタンをクリックするだけで得られないレベルのコントロールを与えます。

結論

[9:15 - 9:30] これら5つのCLIコマンドは、開発中に最も頻繁に実行するタスクを処理します：コンパイル、実行、ライブリロード、古い出力のクリア、リリースのためのパッケージング。 それらはすべて for .NETプロジェクトタイプにわたり、SDKがサポートするすべてのオペレーティングシステムで動作します。

次回、ローカルマシン内、コンテナ内、またはリモートサーバー上でターミナルを開くときに、グラフィカルインターフェースなしで完全な開発サイクルを進めるための語彙をすでに持っていることになります。

例のヒント：dotnet clean && dotnet buildによって単一の行にチェーンすることができます。 これにより、1ステップでスクラッチからのコンパイルが保証され、増分ビルドの間で持続する問題をトラブルシューティングするときに特に便利です。

彼のYouTubeチャンネルで完全なビデオを視聴し、.NET CLIの基本についてさらに洞察を得てください。