.NET Core 2.1グローバルツール

数週間前、.NET Core 2.1 RC1がリリースされました 。 これは、「。NET Core Global Tools」と呼ばれる機能があるSDKの最初のバージョンです。 クロスプラットフォームコンソールユーティリティを作成する簡単な方法を提供します。



.NET Core Global Toolsの使用の基本を学び、中身を簡単に確認します。 .NET Core 2.1 SDKダウンロードして、独自の例を作成してみることもできます。


基本


.NET Coreグローバルツールは、コンソールアプリケーションを含む特別なNuGetパッケージです。 インストールすると、.NET Core CLIはパッケージをダウンロードし、新しいグローバルコンソールコマンドとして使用できるようにします。


ユーザーは、 dotnet tool installコマンドを使用してユーティリティをインストールできます。


 dotnet tool install -g <nuget package name> 

インストール後、パッケージ内のコンソールユーティリティは名前でグローバルにアクセスできます。


 <command name> 

dotnet toolは他のコマンドがあります。 例:


 dotnet tool list -g dotnet tool uninstall -g <nuget package name> dotnet tool update -g <nuget package name> 

ボンネットの下


コンソールユーティリティ付きのNuGetパッケージには、 dotnet publishコマンドの結果として受信したすべてのファイルと、メタ情報を含むいくつかの追加ファイルが含まれています。


dotnet tool install --globalを実行dotnet tool install --globalと、次のことが起こります。


  1. dotnet restore 、パッケージをダウンロードするための特別なオプションで dotnet restoreれます。
  2. ファイルは$HOME/.dotnet/.store/<package id>/<version>フォルダーに解凍されます。
  3. 起動ファイルは、 $HOME/.dotnet/toolsフォルダーに生成されます。

生成された実行可能ファイルは、.NET Core DLLファイルの場所を認識し、それを自動的に起動する小さなコンソールアプリケーション( C ++で記述 )です。


引数--tool-path $installDir指定して--tool-path $installDir dotnet tool installを実行することもできます。 このコマンドは同じことを行いますが、コンソールアプリケーションを$HOME/.dotnet/toolsなく、 $installDirフォルダーに$installDirます。


独自のパッケージを作成する方法


グローバルコンソールユーティリティを作成するには、 .NET Core SDKバージョン2.1が必要です。 このバージョンでは、グローバルコンソールユーティリティでパッケージの名前と内容を管理するためのいくつかのプロジェクト設定が追加されています。


最低限必要なプロジェクトパラメータ:


 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <PackAsTool>true</PackAsTool> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.1</TargetFramework> </PropertyGroup> </Project> 

パッケージアセンブリを制御する追加の(オプション)パラメーター:



これらのパラメーターの使用例:


 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <PackAsTool>true</PackAsTool> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.1</TargetFramework> <ToolCommandName>pineapple</ToolCommandName> <PackageId>dole-cli</PackageId> <PackageVersion>1.0.0-alpha-$(BuildNumber)</PackageVersion> <AssemblyName>Dole.Cli</AssemblyName> </PropertyGroup> </Project> 

パッケージの組み立てとインストール


パッケージは通常どおりにビルドされますdotnet packコマンドを使用しdotnet pack 。 SDKはパラメーターPackAsTool=trueていることを確認し、必要な追加ファイルを自動的に生成します。


 dotnet pack --output ./packages 

--source-feedオプションを使用すると、まだNuGetパッケージリポジトリに公開されていないパッケージをインストールできます。 これは、すべてが正しく行われたことを確認するのに役立ちます。 また、パッケージのバージョンが非リリース(たとえば、 3.0.0-alpha -3つの数字以外のものを含む)である場合、インストール中に明示的に指定する必要があります。


例:


 dotnet tool install -g my-package-name --version 3.0.0-alpha --source-feed ./packages/ 

パッケージの中身


上記で書いたように、 PackAsTool=trueパラメーターがプロジェクトファイルで指定されている場合、 PackAsTool=true dotnet packコマンドは特別な方法でパッケージを収集します。


依存関係


パッケージには、 dotnet buildを介して受け取ったファイルだけでなく、プロジェクトの他のすべての依存関係(接続されているサードパーティのNuGetパッケージ)も含まれます。 コンソールユーティリティが機能するために必要なすべてのファイルは、NuGetパッケージに含まれている必要があります。 dotnet-tool-installコマンドは、 .nuspecファイルの<dependencies> .nuspec指定された依存関係をインストールしません。


DotnetToolSettings.xml


コンソールアプリケーションに関する情報を含む特別なDotnetToolSettings.xmlファイルがDotnetToolSettings.xmlされます。 何らかの理由でこのファイルがパッケージに表示されない場合(たとえば、コンソールユーティリティとして任意のパッケージをインストールしようとすると)、インストール中にエラーが表示されます。


ツールのNuGetパッケージの設定ファイルが無効です。設定ファイル「DotnetToolSettings.xml」がパッケージに見つかりませんでした。

ファイルの内容の例:


 <DotNetCliTool Version="1"> <Commands> <Command Name="my-command-name" EntryPoint="my-file.dll" Runner="dotnet" /> </Commands> </DotNetCliTool> 

現在、 DotnetToolSettings.xmlファイルには次の要件があります。



<packageType name = "DotnetTool" />


<packageType name="DotnetTool" />パラメーターが.nuspecファイルに自動的に追加されます。 例:


 <?xml version="1.0" encoding="utf-8"?> <package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd"> <metadata> <!--     ! --> <packageTypes> <packageType name="DotnetTool" /> </packageTypes> <!-- ... --> </metadata> </package> 

packageType[name]パラメーターがDotnetToolとして指定されていない場合、インストール中にエラーが発生します。


エラーNU1212:awesome-tool 1.0.0のプロジェクトとパッケージの組み合わせが無効です。 DotnetToolReferenceプロジェクトスタイルには、DotnetToolタイプの参照のみを含めることができます

もちろん、これはあまり明確なエラーメッセージではありません。 これを改善するためにGithubに問題があります。


何がうまくいかないか


グローバルユーティリティ-コンピューターではなくユーザーに対してグローバル


.NET Core CLIは、デフォルトでグローバルユーティリティを$HOME/.dotnet/toolsフォルダー(Linux / macOSの場合)または%USERPROFILE%\.dotnet\toolsフォルダー(Windowsの場合)にインストールします。 つまり、 dotnet tool install --globalを使用して、すべてのコンピューターユーザーに対してパッケージをグローバルにインストールすることはできません。 インストールされたユーティリティは、それらをインストールしたユーザーのみが使用できます。


PATH変数にパスがありません


通常、.NET Coreは、インストールされたユーティリティを含むフォルダーへのパスをPATH環境変数に自動的に追加し、フルパスを指定せずに名前でアクセスできるようにします。 しかし、時にはこれが機能しない場合があります。 例:



この場合、コンソールユーティリティの起動時にエラーが表示されます。 例:


bash:my-command-name:コマンドが見つかりません

機能させるには、ユーティリティフォルダーへのPATH変数に追加する必要があります。 たとえば、次のように(追加後、ターミナルを再起動する必要があります)


 cat << \EOF >> ~/.bash_profile # Add .NET Core SDK tools export PATH="$PATH:/Users/<user-name>/.dotnet/tools" EOF 

または、次のように現在のセッションに追加できます。


 export PATH="$PATH:/Users/<user-name>/.dotnet/tools" 

上記の例はMacOS用です。 他のシステムでは、すべてが同様です。 さらに、グローバルコンソールユーティリティをインストールすると、 dotnet tool installコマンドdotnet tool install PATH変数が正しく設定されているdotnet tool install確認し、設定されていない場合は解決策を提案します。


.NET Core CLIがデフォルトのフォルダーにインストールされていません


.NET Core CLIを.zip / .tar.gzアーカイブとしてダウンロードし、デフォルトのフォルダーとは異なるフォルダーに解凍した場合、コンソールユーティリティの起動時にエラーが発生する場合があります。



エラーメッセージには追加情報も含まれます。


これが自己完結型のアプリケーションである場合、そのライブラリは[ここのパス]に存在する必要があります。
これがフレームワーク依存アプリケーションである場合、ランタイムをデフォルトの場所[デフォルトの場所]にインストールするか、DOTNET_ROOT環境変数を使用してランタイムの場所を指定します。

その理由は、パッケージのdotnet tool install時にdotnet tool installコマンドによって生成されるファイルが起動され、デフォルトフォルダーで.NET Coreが検索されるためです。 環境変数DOTNET_ROOT設定することにより、デフォルトのパスをオーバーライドできます。 例:


 # Windows set DOTNET_ROOT=C:\Users\username\dotnet # MacOS/Linux export DOTNET_ROOT=/Users/username/Downloads/dotnet 

GitHubの問題の詳細。


おわりに


.NET Coreのグローバルコンソールユーティリティに会いました。 私の意見では、これは非常にクールなことです。 .NET Coreチームが見落としたことを非常に嬉しく思います。 みんなが使い始めるのを待ちきれません:)



Source: https://habr.com/ru/post/J359006/


All Articles