数週間前、.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と、次のことが起こります。
dotnet restore 、パッケージをダウンロードするための特別なオプションで dotnet restoreれます。- ファイルは
$HOME/.dotnet/.store/<package id>/<version>フォルダーに解凍されます。 - 起動ファイルは、
$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>
パッケージアセンブリを制御する追加の(オプション)パラメーター:
AssemblyNameコンソールアプリケーションの.dllファイルの名前を設定します。ToolCommandNameユーザーがコンソールユーティリティを起動するコマンドの名前。 既定では、.dllファイルの名前( AssemblyNameパラメーターで指定されている)と一致します。
- コマンド名は
dotnet-始まる必要はありません。 スペースなしで任意の名前を使用できます。 - 名前が
dotnet-で始まる場合、ユーティリティはdotnet-ユーティリティのコマンドとして実行できます(同じ名前のコマンドがまだないことを確認してください)。 たとえば、 dotnet-say-mooユーティリティは、 dotnet-say-mooとdotnet say-moo両方を呼び出すことができます。
PackageId -NuGetパッケージの識別子。 デフォルトは、.csprojファイルの名前です。 この識別子はインストール中に指定する必要があります。 ただし、コマンドの名前( ToolCommandName )および.dllファイルの名前( ToolCommandName )とは異なる場合があります。PackageVersion -NuGetパッケージのバージョン(デフォルト1.0.0 )。 または、 VersionSuffix代わりにPackageVersionとVersionSuffix使用できます。
これらのパラメーターの使用例:
<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されます。 何らかの理由でこのファイルがパッケージに表示されない場合(たとえば、コンソールユーティリティとして任意のパッケージをインストールしようとすると)、インストール中にエラーが表示されます。
ツールのNuGetパッケージの設定ファイルが無効です。設定ファイル「DotnetToolSettings.xml」がパッケージに見つかりませんでした。
ファイルの内容の例:
<DotNetCliTool Version="1"> <Commands> <Command Name="my-command-name" EntryPoint="my-file.dll" Runner="dotnet" /> </Commands> </DotNetCliTool>
現在、 DotnetToolSettings.xmlファイルには次の要件があります。
DotnetToolSettings.xmlファイルはtools/$targetframework/any/フォルダーに配置する必要があります。 例: tools/netcoreapp2.1/any/DotnetToolSettings.xml- パッケージには
DotnetToolSettings.xmlファイルが1つだけ含まれている必要があります。 DotnetToolSettings.xmlファイルには、 <Command>セクションを1つだけ記述する必要があります。Runner属性値は"dotnet"なければなりません。EntryPoint属性の値は、 EntryPointファイルと同じフォルダーにある.dllファイルの名前である必要があります。
<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環境変数に自動的に追加し、フルパスを指定せずに名前でアクセスできるようにします。 しかし、時にはこれが機能しない場合があります。 例:
DOTNET_SKIP_FIRST_TIME_EXPERIENCE環境DOTNET_SKIP_FIRST_TIME_EXPERIENCEを追加すると(たとえば、.NET Coreの最初の起動を高速化するために)、 PATH変数の値が最初に使用するときに設定されない場合があります- macOS:
.tar.gzファイルから(および.pkgファイルからではなく)CLIをインストールした場合、 PATH変数を設定する/etc/paths.d/dotnet-cli-toolファイルがない場合があります。 - Linux:シェル環境ファイル、つまり
~/.bash_profileまたは~/.zshrcを手動で編集する必要があります
この場合、コンソールユーティリティの起動時にエラーが表示されます。 例:
bash:my-command-name:コマンドが見つかりません
機能させるには、ユーティリティフォルダーへのPATH変数に追加する必要があります。 たとえば、次のように(追加後、ターミナルを再起動する必要があります)
cat << \EOF >> ~/.bash_profile
または、次のように現在のセッションに追加できます。
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アーカイブとしてダウンロードし、デフォルトのフォルダーとは異なるフォルダーに解凍した場合、コンソールユーティリティの起動時にエラーが発生する場合があります。
- Windows:
A fatal error occurred, the required library hostfxr.dll could not be found - Linux:
A fatal error occurred, the required library libhostfxr.so could not be found - macOS:
A fatal error occurred, the required library libhostfxr.dylib could not be found
エラーメッセージには追加情報も含まれます。
これが自己完結型のアプリケーションである場合、そのライブラリは[ここのパス]に存在する必要があります。
これがフレームワーク依存アプリケーションである場合、ランタイムをデフォルトの場所[デフォルトの場所]にインストールするか、DOTNET_ROOT環境変数を使用してランタイムの場所を指定します。
その理由は、パッケージのdotnet tool install時にdotnet tool installコマンドによって生成されるファイルが起動され、デフォルトフォルダーで.NET Coreが検索されるためです。 環境変数DOTNET_ROOT設定することにより、デフォルトのパスをオーバーライドできます。 例:
GitHubの問題の詳細。
おわりに
.NET Coreのグローバルコンソールユーティリティに会いました。 私の意見では、これは非常にクールなことです。 .NET Coreチームが見落としたことを非常に嬉しく思います。 みんなが使い始めるのを待ちきれません:)