.NET Core Global Tools は.NET Core SDKがインストールされている環境でdotnet系cliツールをlist/install/upgrade/uninstall を行う仕組みです。
この仕組みがでたことで、少なくとも dotnet core製のCLIツールの配布はnugetを経由することで統合的に行うことができるようになりました。 おおむねnpmと同様の感覚で使えるため、npmが入っておらず dotnet だけがはいった環境で便利です。
例えば、CI環境では.NET Coreビルド時に .NET Core SDK は入っているけどnpmはない、など特定のシーンで強力に機能します。 さて、今回はこのインストール、アップグレードに関してみてみましょう。
目次
インストールとアップグレードをまとめて行いたい
.NET Core Global Toolsは、インストールに dotnet tool install、アップグレードに dotnet tool upgrade とそれぞれ別のコマンドを用います。
dockerなど、環境が使い捨ての場合はこれで十分なのでシンプルさはとてもいいことです。
一方で、すでにツールxxxx がインストールされている環境で dotnet tool install --global xxxx を行うと exit code 1 が生じ、インストールされていない環境で dotnet tool upgrade xxxx を行うと exit code 1 が生じます。
つまり、ホスト環境など「すでにツールがインストールされている環境」に対してツールのインストールを保証するシーンではひと手間加える必要があります。
ではUnityBuildRunnerを例にサクッと書いてみましょう。
サンプルはリポジトリに置いておきます。
cmd (Windows環境)
もし bash が使えないgowなども利用できないWindows環境の場合、batで保証するように書いてみましょう。 よくあるコマンドの存在を確認して切り替えれば十分でしょう。
dotnet tool list -g | findstr unitybuildrunner
if ('%errorlevel%' == '1') (
dotnet tool install --global UnityBuildRunner --version 1.1.5
) else (
dotnet tool update --global UnityBuildRunner
)
bash
linux 環境では command を使って探したいところですが、dotnet 自体は成功してしまうので list から grep してお茶を濁します。
if dotnet tool list -g | grep unitybuildrunner;
then
dotnet tool update --global UnityBuildRunner
else
dotnet tool install --global UnityBuildRunner --version 1.1.5
fi
まとめ
dotnet コマンドで保証してくれてもいい気もしつつ、まぁ仕方ない。
Ref
解消するっぽい....? 未インストール状態で、dotnet tool update -g unitybuildrunner は今のところだめっぽい。
