Sdk: Is there a plan to support global tools install like Npm ?

[John0King]

In NodeJs we can use npm install bower -g to install bower or other tools ,
I think dotnet should do it too .
I expect there will be a command like : dotnet tools install <toolname> -g by default the tools put in global shoud build a platform specific binary ( on windows, there will be a <app>.exe file )

and dotnet tools install <toolname> to manage the tools section in project.json.

[leixu2txtek]

nuget ?

[John0King]

yes

[TheRealPiotrP]

Global tools is something we want to pursue, but won't get to it during 1.0 release.

[Petermarcu]

I assume no project file is required for someone to acquire a global tool. Many tools people want to deliver are not about projects. They are about debugging or reverse engineering already built assets.

[noahfalk]

We (the diagnostics folks) would love to use something like this to deliver some diagnostic tools we have in mind.

[gulshan]

Can it be just dotnet install instead of dotnet tools install?

[lt72]

@piotrpMSFT was there any progress on this issue and do we know if this is a committed work item for 2.0?

[TheRealPiotrP]

@lt72 No 2.0 work is committed at this point. we're still getting 1.0 out the door.

[lt72]

@mikem and @noahfalk FYI: our POR for downloading the debugger tools needs to take into account the current state of the art RE: dotnet CLI schedule. See Peter's answers above.

[MartinJohns]

@piotrpMSFT Any updates? 1.0 is already out the door for quite some time, and this feature would really be useful to actually make tools usable.

[ricky-hartmann-zocdoc]

In the npm/node world, installing a package globally allows you to invoke it with nothing else in front of it:

npm install -g webpack
webpack ...

Installed locally, you need to either call it in the scripts of your package.json, or invoke it behind something like npx which checks the global and local stores

npm install --save webpack
npx webpack ...

Maybe I'm wrong, but I feel like the dotnet tools (whether installed locally or globally) should always be invoked with dotnet prefixing it, indicating (whether its local or global) that this is trying to use a tool that comes from the dotnet install step, therefore using the current CLR. Otherwise, wouldn't all tools need to be packaged as standalones (maybe not ideal)?

Potential issue
If I upgrade (say from 2.0.0 to 3.0.0) should I expect the tools I installed when I had 2.0.0 to still work when I try to run them? In most cases with npm/node upgrades, this does work.

[John0King]

My personal opinion : when install a tool globally, dotnet should publish a Self-Contained app , so when you update/remove the dotnet cli or clear the packages cache ,those tools still can work .

[ricky-hartmann-zocdoc]

Yea, the more I'm thinking about it, self contained would be nice after an upgrade of the cli/runtime

[Ghasan]

.NET Standard is backward compatible, so it is safe to assume that it will work. I don't think it is a good idea to package a small tool to a size of 100mb+ just to make it standalone. And I am more inclined into tools being accessible from the terminal directly, with no need for 'dotnet tool'. Just like how we use npm tools.

In case of breaking changes, there should be enough time given for authors to upgrade their tools.

[tmds]

If I upgrade (say from 2.0.0 to 3.0.0) should I expect the tools I installed when I had 2.0.0 to still work when I try to run them?

3.0 can be side-by-side installed to 2.0. If you uninstall 2.0, the tool will give a message it doesn't find the appropriate runtime.
For 1.x, the versioning policy did not allow a 1.1 runtime to execute a 1.0 application. Fortunately, for 2.x this has changed. An application for 2.x will run on all runtimes 2.y (y>=x).

dotnet should publish a Self-Contained app
self contained would be nice after an upgrade of the cli/runtime

Considering runtimes can be installed side-by-side, tools should be published as framework dependent applications. This means they have a dependency on a runtime (e.g. .NET Core 2.x) but not a dependency on a specific platform (e.g. linux-x64).

[John0King]

@Ghasan @tmds Framework dependent applications will be great only if the tools only serve for development .
Self-Contained app will be great for other daily work, for example: bundl and minify js css file, thing's like bower, processing images . those work don't require you to update .net core SDK/Runtime , and will not be effect if you clean up package cache.

and probably easier to implement : create a new project and reference the tools as a PackageReference , and then publish, the project's as a proxy to call the tools Main , and by that we can rename the tools name to a short name

[tmds]

@John0King I don't see at what point a self-contained application would be created.
If I do dotnet install GreatTool. self-contained means I get a linux-x64 app on Linux, a win-x64 app on Windows and an osx-64 app on Mac.

This would be the framework dependent way:
Suppose _GreatTool_ is published as a framework dependent application on NuGet.
When a user does dotnet install GreatTool, dotnet will look at nuget.org and see what versions are available. If the latest version supports a runtime I have install it, dotnet will install the package. Otherwise dotnet will suggest to install a compatible runtime and provide a list of older versions of the package which are compatible with the runtimes I have installed.

[John0King]

tools should be published as framework dependent applications

Do you mean publish to Nuget as framework dependent application (platform irrelevant app) ? If you do, I will agree with you. Self-contained publish process should only happen when you install it.

[tmds]

Self-contained publish process should only happen when you install it.

The publish process for a self-contained application starts from the application source code. It doesn't start from a published framework-dependent application.
Self-containing the application means adding a runtime for the install platform. Instead of adding the runtime to the application, it makes more sense to require the runtime to be installed on the machine. Then all application can share the runtime and it gets patched.

[John0King]

@tmds this is a demo that I manual publish with self-contained publish

project file:

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
    <AssemblyName>CLITools</AssemblyName>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.SecretManager.Tools" Version="2.0.0" />
  </ItemGroup>

Program.cs
C# public static void Main(string[] args) { Microsoft.Extensions.SecretManager.Tools.Program.Main(args); }

add the folder to Path environment variable then it's done.

this is the most easy way , and can change the long name to a short name (without the dotnet- prefix). unfortunately it doesn't work if the tools do not have a public entry point.
I think even without the extra project , it still can publish a self-contained application, because tools can be restore (I saw it in vs output window) , and then copy all the necessary file ( runtime,dotnet.exe,and nuget dependency) to the tools folder, rename dotnet.exe and <toolsname>.dll to <new-tools-name>.exe/.dll , final step： create the <new-tools-name>.deps.json .

[tmds]

Aha. You are suggesting that the way to make the FDD NuGet package callable via a short name is to create and publish a SCD that calls the FDD.
I leave it up to the people doing the implementation to figure out the proper way to do this.

So, we both think tools should be published to NuGet as FDD. That was what I was talking about.

[tmds]

@tonerdo implemented this feature as a cli extension: https://github.com/tonerdo/dotget

[livarcocc]

This is actually being implemented in the CLI directly as well, as global tools. The install tool and pack tool experience just made in to the CLI available from our nightlies at the main branch.

[tmds]

@livarcocc is this 2.1 milestone or 2.2?

[dasMulli]

Just finished a blog post on how to create & use tool packages for dotnet install tool:
https://dasmulli.blog/2018/01/23/exploring-global-net-core-tools/

https://twitter.com/dasmulli/status/955853684876996608

[livarcocc]

It will be 2.1 of .NET Core. 2.1.3xx of the CLI.

[johnkors]

@livarcocc Should ~/.dotnet/tools be automatically added to path on macOS using the latest 2.1.3xx installer?

[livarcocc]

cc @wli3

[wli3]

@johnkors

Should ~/.dotnet/tools be automatically added to path on macOS using the latest 2.1.3xx installer?

Yes, it is automatically added to path on macOS using the installer.

[wli3]

issue on dotnet-x not working on mac https://github.com/dotnet/cli/issues/8450

[John0King]

@livarcocc
Will those tools run after dotnet nuget locals global-packages --clear ?

[wli3]

Yes, they will still run. Tools asset is stored in a different place.

[johnkors]

@wli3 , ok on macOS I had to manually add ~/.dotnet/tools to PATH. I tried re-launching the terminal as well.

[dasMulli]

@johnkors you don’t happen to use zsh with oh-my-zsh?
That one pins the path on install and macOS’ own path helper no longer works..

[johnkors]

Yeah, I'm using zsh. Makes sense. Thanks, @dasMulli !

[wli3]

@johnkors @dasMulli I added an issue on different shell support on mac. https://github.com/dotnet/cli/issues/8466 suggestions are welcome

[BrunoJuchli]

Will this also cover use cases such as installing a test runner?
Will it support installing different versions of that tool side-by-side?
Will a solution/project be able to specify a dependency on a tool (& -version)?

[wli3]

Will this also cover use cases such as installing a test runner?
Will it support installing different versions of that tool side-by-side?
Will a solution/project be able to specify a dependency on a tool (& -version)?

As plan for 2.1.300 all the answers are no

[BrunoJuchli]

@wli3
Thanks for the clarification.

@rohit21agrawal
In that case I'd like to note that the comment in https://github.com/NuGet/Home/issues/1521

Dotnet tools (available with 15.7 shortly) will bridge this gap.
dotnet/cli#5147

is inaccurate as there's still going to be a lot of use cases missing that have been possible with solution level packages.

[John0King]

may be create a new tool dotnet-dnx as a default global tool . use dnx tool-name to find and excute tool in project file's <CliToolsReference /> , and tools assert are just normal nuget packages (has version) just like current tools , and dnx without toolname can be use for C# interactive (like in visual studio)

[dasMulli]

I've heard people ask offline for a "pull and execute" 1-step tool invoke command that - like docker run or npx will fetch the "thing" automatically and then use it, so a dotnet run tool xunit (or something shorter, my naming skills don't seem to improve) could be an alias for dotnet install tool -g xunit && dotnet xunit [other args].
Wondering if more ppl are interested in this.

[johnkors]

AFAIK, dotnet build does a dotnet restore unlesss you opt out, so @dasMulli s proposal would at least make it follow that pattern.

[livarcocc]

We have now implemented our global tools feature through dotnet tool install (formerly dotnet install tool).

It has a local tool version (through --tool-path instead of --global) along with uninstall, list and update.

As such, I am going to close this issue. If there are specific feature requests around the feature we have built in 2.1.300, I would suggest filling new separate issues for those asks.