Port CLI tools to be global tools [Breaking change]

[natemcmaster]

⚠️ this will be a breaking change for some users because it drops support for tools working as a DotNetCliToolReference. The current design of CLI global tools does not allow structuring a package that supports both DotNetCliToolReference and the new dotnet install tool verb. Update: we are going to use new package IDs, instead of attempting to update existing ones.

Resolves #368

Ports our command-line tools to support global CLI commands.

The following NEW packages are created by this PR. Old packages won't be upgraded to support global tools.

Old Package ID (DotNetCliToolRefererence)	New Package ID (dotnet install tool)
Microsoft.DotNet.Watcher.Tools	dotnet-watch
Microsoft.Extensions.SecretManager.Tools	dotnet-user-secrets
Microsoft.Extensions.Caching.SqlConfig.Tools	dotnet-sql-cache
Microsoft.AspNetCore.DeveloperCertificates.Tools (* has never shipped)	dotnet-dev-certs

cc @livarcocc @wli3 @DamianEdwards @glennc

[javiercn]

Looks good to me. It's missing the dev-certs rename.

[natemcmaster]

I decided to keep the rename separate from the global-tool conversion: #371

[natemcmaster]

cc @bricelam for dotnet-ef

[DamianEdwards]

We need to discuss the breaking nature of this. I'm not ready to say this is OK, we might need to consider retiring the project tool packages and put the global tools in new packages, or something else.

[natemcmaster]

Talked a little in person with @DamianEdwards. We think new package IDs is probably the best way to help users manage this big change.

The install gesture will be dotnet install tool <PackageId>, so the shorter the ID the better.
Here are some ideas for new package IDs we could use:

dotnet-*

• dotnet-watch
• dotnet-user-secrets
• dotnet-ef (cc @divega)
• dotnet-dev-certs

Microsoft.Tool.*

• Microsoft.Tool.Watch
• Microsoft.Tool.UserSecrets
• Microsoft.Tool.EFCore
• Microsoft.Tool.DevCerts

Microsoft.DotNet.Tool.*

Same as above, just with a longer prefix "Microsoft.DotNet.Tool"

Thoughts @DamianEdwards @muratg @Eilon @ajcvickers @divega @glennc ?

[DamianEdwards]

I'm leaning towards the very short names, e.g. dotnet-watch. I think it's time.

[natemcmaster]

+1 for short names

[bricelam]

As I've been trying to do for years, I'd like to package all of EF's global tools inside the Microsoft.EntityFrameworkCore.Tools package. Ultimately, we may have two tools: dotnet-ef for working with projects on the dev box, and ef for working with assemblies on the server. (in addition to the PMC tools)

[bricelam]

Have we talked to other tool builders about packaging/naming? I imagine there are some other toolchains that want to (eventually) ship multiple tools in a single package...

[natemcmaster]

So far, the global tools discussion has been mostly done internally. I don't think we've looped in external contributors into the discussion yet.

I also would like to see enough flexibility in the global tools design to allow multiple tools in one package, and re-using a runtime package as a tool package, but the current design wouldn't allow that.

[bricelam]

multiple tools in one package

This is on their radar for the future, right?

re-using a runtime package as a tool package

What's preventing this now?

[natemcmaster]

Per discussion this afternoon, I've updated the PR to include the rename of the package ID. The following NEW packages are created by this PR. Old packages won't be upgraded to support global tools.

Old Package ID (DotNetCliToolRefererence)	New Package ID (dotnet install tool)
Microsoft.DotNet.Watcher.Tools	dotnet-watch
Microsoft.Extensions.SecretManager.Tools	dotnet-user-secrets
Microsoft.Extensions.Caching.SqlConfig.Tools	dotnet-sql-cache
Microsoft.AspNetCore.DeveloperCertificates.Tools (* has never shipped)	dotnet-dev-certs

[divega]

@natemcmaster sorry for the belated response. I think this is reasonable given all the constraints. It seems if we stick to this naming convention it should be easier to discover what to do when a tool I want to run is not installed. We could even consider improving the error you get from the CLI to say "missing a global tool? Try dotnet install -g dotnet-xyz" (or whatever the command is for installing it).

[javiercn]

Signing off for the dev-cert parts. I'll let @bricelam sign-off for the EF tools, but everything else looks good to me.

[natemcmaster]

Two infrastructure issues we should resolve before we merge this:

• https://github.com/aspnet/Coherence-Signed/issues/718 - ensure we don't sign Newtonsoft.Json and other files that end up in the nupkg
• Add DotNetToolPackageRule to NGPV BuildTools#523 - update NuGetPackageVerifier to understand global CLI tool packages

[natemcmaster]

Updated the "packageType" value to DotnetGlobalTool. This is just a placeholder value. The spec hasn't defined-yet what the value should be.

[wli3]

FYI package type issue is here NuGet/Home#6198

[natemcmaster]

Thanks. I updated to "DotnetTool" per this comment https://github.com/dotnet/designs-microsoft/pull/12#discussion_r157843056

[natemcmaster]

Added infrastructure improvements to allow us to sign our own assemblies, 3rd-party sign JSON.NET, and skip signing for assemblies that come from the dotnet-core team (should already be signed). cref aspnet/BuildTools#531