dotnet cliは、.Net Coreの最も便利な機能の1つです。この記事では、いくつかの.Net OSSツールがdotnet cliを使用する方法と、毎日の開発で新しいcliツールを使用する方法を紹介します。

テキスト

要点

dotnet cliは、特に10年以上前の.Netテクノロジーと比較して、.Netプロジェクトに基づく自動化とスクリプト作成を非常にシンプルにします。
dotnet cliスケーラビリティモデルは、外部.NETで記述されたコマンドラインプログラムをNugetを介して自動ビルドに統合することを可能にする条件を作成します。
dotnet cliを使用すると、ビルドスクリプトでソリューションをテストできます。
dotnet cliのテスト出力は、継続的インテグレーション（CI）の使用に役立ちます。
Dockerのようなコンテナーテクノロジーを使用する方が、dotnet cliを使用するよりもはるかに簡単です。

.NET Core 2.0のリリースにより、Microsoftは、2016年に最初にリリースされた、ユニバーサル、モジュラー、クロスプラットフォーム、およびオープンソースプラットフォームの次のメジャーバージョンを手に入れました。.NET Coreは多くのAPIを作成しており、現在のバージョンの.NETフレームワークで使用できます。もともとは次世代ASP.NETソリューション用に作成されましたが、現在はモノのインターネット、クラウド、次世代モバイルソリューションなど、他の多くのシナリオの原動力と基盤となっています。.NET Coreに関する第2シリーズの記事では、.NET Coreの利点と、それが従来の.NET開発者だけでなく、堅牢で効率的な市場を提供する必要があるすべての開発者にどのように役立つかをさらに探ります。技術スタッフ向けの経済的なソリューション。

最近誰かが私に尋ねました、古い、フル機能の.NETをためらったり、撤回できない人と比較して.NET Coreを選択する利点は何ですか？回答で、.NET Coreのパフォーマンスが向上し、csprojファイル形式が改善され、ASPのテスト性が改善され、クロスプラットフォームであると述べます。

いくつかのOSSツールの作成者（Marten、StructureMap、およびAlbaがこのプロジェクトの例として引用）として、個人的に私にとって最大の利点は、dotnet cliの出現です。私は個人的に、新しい.NET SDK csprojファイル形式と組み合わせて使用すると、dotnet cliツールを使用すると、プロジェクトの作成とビルドスクリプトの管理が簡単になります。ビルドスクリプトでテストをより簡単に実行でき、Nugetパッケージをより簡単に使用および配布できます。また、cli拡張機能メカニズムは、Nugetパッケージを通じて配布されたカスタム実行可能ファイルを自動ビルドにマージするのに理想的です。

dotnet cliの使用を開始するには、まず開発マシンに.NET SDKをインストールします。インストールが完了したら、役立つヒントをいくつか示します。

コマンドラインプロンプトからどこでも使用できるように、PATHにグローバルに「dotnet」ツールをインストールします。
dotnet cliはLinuxスタイルのコマンド構文を採用し、「– word [値]」を使用して選択したパラメーターを表すか、省略形「-w [値]」を直接使用します。GitまたはNode.jsのコマンドラインツールに慣れている場合は、dotnet cliに慣れているはずです。
「Dotnet --help」は、インストールされているコマンドといくつかの基本的な構文の使用法を一覧表示します。
「Dotnet --info」は、使用しているdotnet cliのバージョンを通知します。継続的インテグレーションビルドでこのコマンドを呼び出してローカルで動作し、ビルドサーバーに障害が発生したときにトラブルシューティングすることをお勧めします。逆の場合も同様です。
この記事では.NET Coreについて説明していますが、完全な.NET Frameworkの以前のバージョンでは、新しいSDKプロジェクト形式とdotnet cliを使用できることに注意してください。

コマンドラインでのHello World

dotnet cliのハイライトのいくつかを簡単に理解するために、単純な「Hello World」ASP.NET Coreアプリケーションを構築したいとします。しかし、楽しみのために、いくつかの新しいトリックを追加しましょう：

1.当社のWebサービスは、別のプロジェクトで自動的にテストされます。

2.これはクールな方法であるため、Dockerコンテナーを介してサービスをデプロイします（より多くのdotnet cliを示しています）。

3.もちろん、可能な限りdotnet cliを使用します。

このコードの最終結果を確認したい場合は、このGitHubリポジトリを確認してください。

まず、「DotNetCliArticle」という空のディレクトリから始めて、お気に入りのコマンドラインツールをそのディレクトリに開きます。まず、「dotnet new」コマンドを使用して、ソリューションファイルと新しいプロジェクトを生成します。.NET SDKには、一般的なプロジェクトタイプまたはファイルを作成するためのいくつかの一般的なテンプレートと、アドインとして使用できる他のテンプレートが付属しています（これについては後で詳しく説明します）。マシンで使用可能なテンプレートを表示するには、次のコマンドdotnet new -helpを使用できます。次の出力が表示されます。

空のソリューションファイル用のslnテンプレートがあることに気付くでしょう。テンプレートを使用してdotnet new slnコマンドを入力すると、次の出力が生成されます。

コードをコピー

テンプレート「ソリューションファイル」が正常に作成されました。

デフォルトでは、このコマンドは、含まれているディレクトリに基づいてソリューションファイルに名前を付けます。ルートディレクトリに「DotNetCliArticle」という名前を付けたため、生成されたソリューションファイルは「DotNetCliArticle.sln」です。

次に、次のコマンドを使用して、「Hello、World」の実際のプロジェクトを追加します。

コードをコピー

dotnet new webapi-出力HeyWorld

上記のコマンドは、「output」パラメーターで選択された「HeyWorld」の「webapi」テンプレートを使用することを意味します。このテンプレートは、ヘッドレスAPIに適した合理化されたMVCコアプロジェクト構造を生成します。同様に、デフォルトの方法では、プロジェクトファイルが置かれているディレクトリに従ってプロジェクトファイルに名前を付けるので、「HeyWorld.csproj」という名前のファイルとディレクトリ内のすべての基本ファイルを取得して、最小限のASP.NET MVC Core APIプロジェクトを形成します。テンプレートは、ASP.NET Coreへの必要なすべてのNuget参照も設定します。これは、新しいプロジェクトを開始するときに使用します。

たまたま小さなGitリポジトリでビルドしたため、Git addを使用して新しいファイルを追加した後、Gitステータスを使用して新しく作成されたファイルを表示しました。

コードをコピー

新しいファイル：HeyWorld / Controllers / ValuesController.cs 
新しいファイル：HeyWorld / HeyWorld.csproj 
新しいファイル：HeyWorld / Program.cs 
新しいファイル：HeyWorld / Startup.cs 
新しいファイル：HeyWorld / appsettings.Development.json 
新しいファイル：HeyWorld / appsettings .json

ここで、空のソリューションファイルに新しいプロジェクトを追加するには、次のように「dotnet sln」コマンドを使用できます。

コードをコピー

dotnet sln DotNetCliArticle.sln追加HeyWorld / HeyWorld.csproj

これで、Visual Studio.NET（またはJetBrains Rider）を開かずに、新しいASP.NET Core APIサービスをシェルとして使用できます。さらに進んで、実際のコードを記述する前にテストプロジェクトを開始するには、次のコマンドを発行します。

コードをコピー

dotnet new xunit --output HeyWorld.Tests dotnet 
sln DotNetCliArticle.sln追加HeyWorld.Tests / HeyWorld.Tests.csproj

上記のコマンドは、xUnit.NETを使用して新しいプロジェクトを作成し、新しいプロジェクトをソリューションファイルに追加します。テストプロジェクトには「HeyWorld」プロジェクトへの参照が必要ですが、幸い、次のように優れた「dotnet add」ツールを使用してプロジェクト参照を追加できます。

コードをコピー

dotnet add HeyWorld.Tests / HeyWorld.Tests.csproj reference HeyWorld / HeyWorld.csproj

ソリューションを開く前に、いくつかのNugetリファレンスがあることを知っていたので、テストプロジェクトでそれらを使用したいと思いました。私が選択したアサーションツールはShoullyなので、コマンドラインに別の呼び出しを発行して、shoullyの最新バージョンへの参照を追加します。

コードをコピー

dotnetはHeyWorld.Tests / HeyWorld.Tests.csprojパッケージを追加する必要があります

コマンドラインの出力は次のとおりです。

コードをコピー

info：パッケージ 'Shouldly'のPackageReferenceをプロジェクト 'HeyWorld.Tests / HeyWorld.Tests.csproj'に追加しています。
ログ：/Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj ...のパッケージの復元
info：GET https://api.nuget.org/v3-flatcontainer/shouldly/index.json 
info： OK https://api.nuget.org/v3-flatcontainer/shouldly/index.json 109ms 
info：パッケージ 'Shouldly'は、プロジェクト 'HeyWorld.Tests / HeyWorld.Tests.csproj'で指定されたすべてのフレームワークと互換性があります。
info：パッケージ 'Shouldly'バージョン '3.0.0'のPackageReferenceがファイル '/Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj'に追加されました。

次に、Albaという名前のテストプロジェクトに少なくとも1つのNuget参照を追加します。AspNetCore2を使用して、新しいWebアプリケーションのHTTPコントラクトテストを記述します。

コードをコピー

dotnet追加HeyWorld.Tests / HeyWorld.Tests.csprojパッケージAlba.AspNetCore2

コードを使用して確認する前に、コマンドラインで次のコマンドを発行して、ソリューション内のすべてのプロジェクトをビルドし、すべてが正しくコンパイルされることを確認します。

コードをコピー

dotnetビルドDotNetCliArticle.sln

HeyWorldプロジェクトのAlba.AspNetCore2とASP.NET Core Nugetの間の参照のダイヤモンド依存バージョン間の競合により、コンパイルはありません。ただし、この問題は簡単に解決できるため、心配しないでください。Microsoft.AspNetCoreのバージョン依存関係を修正するだけです。テストプロジェクトのすべてのNugetは次のようになります。

コードをコピー

dotnetはHeyWorld.Tests / HeyWorld.Tests.csprojパッケージMicrosoft.AspNetCore.All --version 2.1.2を追加します

上記の例では、「-version」フラグを「2.1.2」の値で使用すると、Nugetフィードにある最新バージョンだけでなく、そのバージョンへの参照が修正されます。

Nugetの依存関係の問題が解決したかどうかを再度確認するには、次のコマンドを使用して確認できます。すべてを再コンパイルするよりも高速です。

コードをコピー

dotnet clean && dotnet restore DotNetCliArticle.sln

経験豊富な.NET開発者として、一時的な/ objおよび/ binフォルダーに残っているファイルについて非常に心配しています。そのため、参照時にドロップされたものを変更しようとする場合に備えて、Visual Studioの「Clean Solution」コマンドを使用します。コマンドラインから「dotnet clean」コマンドを実行することは、まったく同じ操作です。

同様に、よく知られているNuget依存関係の問題については、「dotnet restore」コマンドがソリューションでそれを解決しようとしました。この場合、「dotnet restore」を使用すると、完全なコンパイルを実行しなくても、潜在的な競合や欠落しているNuget参照をすばやく見つけることができます。最新バージョンのdotnet cliでは、「dotnet build / test / pack / etc」を呼び出すと、Nugetの解析が自動的に行われ（この動作はタグで上書きできます）、最初にNugetが必要になります。

呼び出した "dotnet restore DotNetCliArticle.sln"は、問題なく正常に実行を終了したので、最終的にコードを書く準備をすることができます。選択したC＃エディターを開いて、HeyWorldにコードファイルを追加します。テストプロジェクトには、新しいHeyWorldアプリケーションの「GET：/」ルートから取得する動作を指定する非常に単純なHTTPプロトコルテストが含まれています。

コードをコピー

System.Threading.Tasksを使用します。
アルバを使用します。
Xunitを使用します。
名前空間HeyWorld.Tests 
{ 
public class verify_the_endpoint 
{ 
[Fact] 
public async Task check_it_out（）
{ 
using（var system = SystemUnderTest.ForStartup <Startup>（））
{ 
await system.Scenario（s => 
{ 
s.Get.Url（ " / "）; 
s.ContentShouldBe（" Hey、world。 "）; 
s.ContentTypeShouldBe（" text / plain; charset = utf-8 "）; 
}）; 
} 
} 
} 
}

結果ファイルはHeyWorld.Testsディレクトリに適切な名前（verify_the_endpoints.csなど）で保存する必要があります。

Albaのメカニズムを深く理解する前に、新しいHeyWorldアプリケーションのホームページのルーティングで「Hey、world」と書く必要があります。HeyWorldアプリケーションで実際のコードを記述していませんが、このテストを実行して、正しく接続できるかどうか、または「合理的な理由」で失敗するかどうかを確認できます。

コマンドラインに戻ると、次のコマンドを使用して、テストプロジェクトのすべてのテストを実行できます。

コードをコピー

dotnet test HeyWorld.Tests / HeyWorld.Tests.csproj

まだ何も実装されていないため、テストの1つは失敗し、次の出力が得られます。

コードをコピー

ビルドを開始
しました。お待ちください... ビルドが完了しました。
/Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Version=v2.1）Microsoft（R）
テスト実行コマンドラインツールバージョン15.7のテスト実行.0 
Copyright（c）Microsoft Corporation。全著作権所有。
テストの実行を開始してい
ます。お待ちください... テストの総数：1.合格：1.失敗：0.スキップ：0 
.テストの実行が成功しました。
テスト実行時間：2.4565秒

出力を合計するためにテストが実行されましたが、失敗しました。テストが失敗した理由に関する情報を提供する標準のxUnit出力も確認できます。ここで、「dotnet test」コマンドは終了コードを返すことに注意してください。すべてのテストに合格すると、0を返し、成功を示します。テストが失敗すると、ゼロ以外の終了コードを返し、失敗を示します。これは継続的インテグレーション（CI）スクリプトにとって非常に重要であり、ほとんどのCIツールは任意のコマンドの終了コードを使用して、ビルドがいつ失敗したかを判断します。

上記のテストは「合理的な理由」、つまりテストツールが実際のアプリケーションをガイドできるように見えるために失敗したと思います。コードがまだ記述されていないため、404応答を取得したいと考えています。次に、予想される動作のためにMVCコアエンドポイントを実装しましょう。

コードをコピー

パブリッククラスHomeController：Controller 
{ 
[HttpGet（ "/"）] 
public string SayHey（）
{ 
return "Hey、world！"; 
} 
}

（前のコードはHeyWorld \ startup.csファイルに追加クラスとして追加する必要があることに注意してください）

コマンドラインに戻り、前の「dotnet test HeyWorld.Tests / HeyWorld.Tests.csproj」コマンドを実行して、この結果を確認します。

コードをコピー

ビルドを開始
しました。お待ちください... ビルドが完了しました。
/Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Version=v2.1）Microsoft（R）
テスト実行コマンドラインツールバージョン15.7のテスト実行.0 
Copyright（c）Microsoft Corporation。全著作権所有。
テストの実行を開始してい
ます。お待ちください... テストの総数：1.合格：1.失敗：0.スキップ：0 
.テストの実行が成功しました。
テスト実行時間：2.4565秒

テストに合格したので、実際のアプリケーションを実行してみましょう。「dotnet new webapi」テンプレートはインプロセスのKestrelウェブサーバーを使用してHTTPリクエストを処理するため、新しいHeyWorldアプリケーションを実行するために必要なのは、次のコマンドを使用してコマンドラインから開始することだけです。

コードをコピー

 dotnet run --project HeyWorld / HeyWorld.csproj

上記のコマンドを実行すると、次の出力が得られます。

コードをコピー

HeyWorld / Properties / launchSettings.jsonからの起動設定の使用... 
：Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager [0] 
ユーザープロファイルが利用可能です。'/Users/jeremydmiller/.aspnet/DataProtection-Keys'をキーリポジトリとして使用します。鍵は保存時に暗号化されません。
ホスティング環境：開発
コンテンツのルートパス：/ Users / jeremydmiller / code / DotNetCliArticle / HeyWorld 
リスニング：https：// localhost：5001 
リスニング：http：// localhost：5000 
アプリケーションが開始されました。Ctrl + Cを押してシャットダウンします。

現在実行中の新しいアプリケーションをテストするには、次のようにブラウザーでナビゲートします。

HTTPS設定の処理は、この記事の範囲を超えています。

すべてのコマンドは、ソリューションのルートフォルダーとして設定された現在のディレクトリで実行されることを前提としています。現在のディレクトリがプロジェクトディレクトリで、* .csprojが1つしかない場合。次に、ディレクトリに「dotnet run」と入力するだけです。テスト済みのWeb APIアプリケーションが完成したので、DockerイメージにHeyWorldを配置しましょう。.NET Coreアプリケーションをドッキングするための標準テンプレートを使用して、次の内容のDockerfileをHeyWorldプロジェクトに追加します。

コードをコピー

FROM microsoft / 
dotnet ：sdk AS build-env WORKDIR / app 
csprojをコピーして個別のレイヤーとして復元
COPY * .csproj ./ 
RUN dotnet restore 
他のすべてをコピーして
COPY をビルドします。./ 実行dotnet 
publish -cリリース-o out 
ビルドランタイムイメージ
FROM microsoft / dotnet：aspnetcore-runtime 
WORKDIR / app 
COPY --from = build-env / app / out。
ENTRYPOINT ["dotnet"、 "HeyWorld.dll"]

（前のテキストは、プロジェクトディレクトリのDockerfileという名前のテキストファイル（この例ではHeyWorld \ Dockerfile）に保存する必要があります）。

この記事はdotnet cliについてのみなので、Dockerfileでの2つの使用法に焦点を当てたいと思います。

1. "dotnet restore"-上で学んだように、このコマンドはアプリケーションのすべてのNuget依存関係を解決します。

2.「dotnet publish -c Release -o out」-「dotnet publish」コマンドは、指定されたプロジェクトをビルドし、アプリケーションを構成するすべてのファイルを指定された場所にコピーします。この例では、「dotnet publish」は、コンパイルされたアセンブリ、Nuget依存関係から参照されるすべてのアセンブリ、構成ファイル、およびHeyWorld自体のcsprojファイルで参照されるすべてのファイルをコピーします。

上記の使用法では、「-c Release」フラグを使用して「リリース」構成でコンパイルするように「dotnet publish」に明示的に指示する必要があることに注意してください。エンコードに使用されるこれらのdotnet cliコマンド（「build」、「publish」、「pack」など）が指定されていない場合、デフォルト値として「Debug」が使用されます。この動作に注意してください。Nugetまたはアプリケーションを本番用にリリースする場合は、必ず「-c Release」または「-configuration Release」を指定してください。思い出させないで私を責めないでください。

サイクル全体を完了するために、次のコマンドを使用して、Docker経由で小さなHeyWorldアプリケーションをビルドおよびデプロイできます。

コードをコピー

docker build -t heyworld。
docker run -d -p 8080：80 --name myapp heyworld

最初のコマンドは、アプリケーション「heyworld」用のDockerイメージをローカルでビルドして公開します。2番目のコマンドは、実際にアプリケーションを「myapp」という名前のDockerコンテナーとして実行します。ブラウザを開いて「http：// localhost：8080」にアクセスして確認できます。

まとめ

dotnet cliは、特に10年以上前の.NETテクノロジーと比較して、.NETプロジェクトに基づく自動化とスクリプト作成を非常にシンプルにします。多くの場合、タスクベースのビルドスクリプトツール（Cake、Fake、Rake、Psakeなど）を使用せず、dotnet cliにのみ委任された単純なシェルスクリプトを選択することもできます。さらに、dotnet cliスケーラビリティモデルにより、外部の.NET承認コマンドラインアプリケーションをNugetを介して自動ビルドプログラムに簡単に配布できます。

著者についてJeremy Miller（ジェレミーミラー）は、ミズーリ州の農業コミュニティで育ちました。そこでは、「Shade Mechanics」という名前の「特別な」人々のグループがあります。通常、彼らは世界で最も権威のある人々ではありませんが、機械的な問題を解決するノウハウを持ち、無謀で恐れを知らない人です。ブロックに駐車されている通勤車から2本の足が突き出ていることに気付いた場合、彼は修理工である必要があります。。彼の周りに捨てられたビーターは役に立たないわけではありません。彼は少しずつ細かい調整を行ってから、お客様のニーズに基づいて創造的なソリューションを考え出します。その評判にもかかわらず、日陰の整備士は物事を実行する方法を知っています。Millerには特別な機械的能力はありませんが（機械工学の学位は持っていますが）、シェードメカニックのような開発者であると考えています。放棄されたオープンソースプロジェクトの断片は、彼のハードドライブのいたるところになければなりません。.NET Core 2.0のリリースにより、Microsoftは、2016年に最初にリリースされた、ユニバーサル、モジュラー、クロスプラットフォーム、およびオープンソースプラットフォームの次のメジャーバージョンを手に入れました。.NET Coreは多くのAPIを作成しており、現在のバージョンの.NETフレームワークで使用できます。もともとは次世代ASP.NETソリューション用に作成されましたが、現在はモノのインターネット、クラウド、次世代モバイルソリューションなど、他の多くのシナリオの原動力と基盤となっています。.NET Coreに関する第2シリーズの記事では、.NET Coreの利点と、それが従来の.NET開発者だけでなく、堅牢で効率的な市場を提供する必要があるすべての開発者にどのように役立つかをさらに探ります。技術スタッフ向けの経済的なソリューション。

ご不明な点がございましたら、eコマース研修橋口千代美にご連絡ください。

1つの記事で、.NET CLIをすばやく読むことができます！

テキスト

まとめ

おすすめ