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

.NET --info で環境を確認する

[0:31 - 1:25] プロジェクトコマンドを実行する前に、Timは開発環境を確認し始めます。 dotnet コマンドは単独でCLIがインストールされ、パスにアクセス可能かどうかを確認しますが、dotnet --info はさらに進みます：

dotnet --info

dotnet --info

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

コマンド 1: .NET build

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

dotnet build

dotnet build

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

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

コマンド 2: .NET run

[3:44 - 5:42] build がコンパイルで止まるところ、run は次のステップに進み、アプリケーションを起動します：

dotnet run

dotnet run

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

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

コマンド 3: .NET watch

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

dotnet watch

dotnet watch

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

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

コマンド 4: .NET clean

［7:06 - 7:56］(https://www.youtube.com/watch?v=aSmmh-F5KCw&t=426) ビルドアーティファクトはbin および obj ディレクトリに蓄積されます。時折、古いコンパイル済みファイルが最新のコード変更が反映されない、またはローカルでビルドが成功しても新しいマシンで失敗するなどの混乱を招くことがあります。clean コマンドはこれを解決します：

dotnet clean

dotnet clean

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

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

コマンド 5: .NET publish

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

dotnet publish

dotnet publish

build がローカルデバッグに適した出力を生成する一方で、publish はデプロイ準備が整ったパッケージを作成します。 コンパイル済みのアセンブリ、構成ファイル、静的資産、および必要なランタイムコンポーネントは、サーバーに直接コピーできる publish フォルダに配置されます。

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

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

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

結論

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

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

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

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