dotnet tool install on 2.1 is broken out of the box

[omajid]

Now that tools for .NET Core 2.2 are available on nuget.org, things break on .NET Core 2.1 because the 2.2 tools are picked up by dotnet tool install over 2.1 tools.

This can be worked around by specifying --version explicitly.

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.500
 Commit:    b68b931422

Runtime Environment:
 OS Name:     fedora
 OS Version:  29
 OS Platform: Linux
 RID:         fedora.29-x64
 Base Path:   /usr/lib64/dotnet/sdk/2.1.500/

Host (useful for support):
  Version: 2.1.6
  Commit:  3f4f8eebd8

.NET Core SDKs installed:
  2.1.500 [/usr/lib64/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 2.1.6 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

$ dotnet dev-certs

Welcome to .NET Core!
---------------------
Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs

Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
Cannot find command 'dotnet dev-certs', please run the following command to install

dotnet tool install --global dotnet-dev-certs
$ dotnet tool install -g dotnet-dev-certs
error NU1202: Package dotnet-dev-certs 2.2.0 is not compatible with netcoreapp2.1 (.NETCoreApp,Version=v2.1) / any. Package dotnet-dev-certs 2.2.0 supports: netcoreapp2.2 (.NETCoreApp,Version=v2.2) / any
The tool package could not be restored.
Tool 'dotnet-dev-certs' failed to install. This failure may have been caused by:

* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
$ dotnet tool install -g dotnet-dev-certs --version 2.1.1
You can invoke the tool using the following command: dotnet-dev-certs
Tool 'dotnet-dev-certs' (version '2.1.1') was successfully installed.

cc @tmds @RheaAyase @aslicerh

[livarcocc]

@wli3

[dagood]

+cc @nguerrera as well, cli/sdk source-build champion.

Some extra context: the reason this affects source-build in particular is that the source-built SDK can't include ASP.NET tools like the Microsoft one does, so installing tools is the only way to get them.

[wli3]

root cause is here dotnet/sdk#2698

[tmds]

root cause is here dotnet/sdk#2698

That cause is not so clear to me.

It seems the sdk picks the latest version of the tool without considering the current runtime. Because the tool relies on a newer runtime, the installation then fails. Is that the cause?

[dagood]

@wli3 I don't think that applies to this issue--it looks like dotnet/sdk#2698 is about the 2.2.0 tool package not working once installed, but in this issue, we don't restore the 2.2.0 package at all. (And we don't want to restore 2.2.0 in the first place, because it's incompatible with the 2.1.x Runtime being used.)

Instead, we want to restore some 2.1.x package that's compatible with the 2.1.x Runtime/TFM.

[wli3]

@tmds @dagood
Sorry i mixed the issue. This is by design, you need a higher runtime to run this tool. And in this case there is only Microsoft.NETCore.App netcoreapp2.2 the machine but dotnet-dev-certs 2.2.0 need netcoreapp2.2

[wli3]

Although dotnet/sdk#2698 will cause it unable run even new runtime is installed

[tmds]

This is by design

This means, the 'tool install' command breaks, when the tool developer has updated their package on nuget.org.
It would make sense to consider the current runtime, when picking a version of the tool to install. That would avoid this breakage.

'requires a runtime that is not installed' should be added to 'This failure may have been caused by'.

[wli3]

It would make sense to consider the current runtime, when picking a version of the tool to install. That would avoid this breakage.

If the package is muti targeted. It will pick the most fit runtime.

[tmds]

1. A user has .NET Core 2.1 installed, this works: dotnet tool install -g dotnet-dev-certs
2. Microsoft uploads dotnet-dev-certs 2.2 which runs on netcoreapp2.2.
3. A user has .NET Core 2.1 installed, this fails: dotnet tool install -g dotnet-dev-certs

It would be good if 1 and 3 behave consistent for the user.

[dagood]

If the package is muti targeted. It will pick the most fit runtime.

@natemcmaster, is it reasonable to suggest that the latest dotnet-dev-certs package should multitarget netcoreapp2.1 and netcoreapp2.2? With these tool packages being linked to the .NET Core Runtime version trains, it doesn't seem to me like a reasonable change at first glance. I suppose the suggestion can also be thought of as making these tool packages out of band releases.

Another alternative is adding some additional highly focused source-building for just these packages, and actually include them in the source-built SDK. I don't remember if we looked at that before, or if that requires non-source-buildable dependencies.

[tmds]

This applies to any tool. It's not source-build specific.

[dagood]

It does, but I imagine tools that aren't normally delivered as part of the SDK are expected to only have one version train, and they can multitarget or target an earlier TFM that's compatible with future runtimes. So far, I think using a source-built SDK is the only reason you'd need to install tool packages that would normally be delivered with the SDK (and therefore have multiple version trains).

[tmds]

and they can multitarget or target an earlier TFM that's compatible with future runtimes

Yes, the current design requires multi-targeting or an earlier TFM. This is a burden for the tool developer, and eventually, when a target is dropped, the tool user gets the broken install command.

[nguerrera]

This has also been a pain point for traditional nuget packages where you are offered incompatible upgrades to latest that have dropped support for your TFM. I recall some discussion about adressing that, but I don't know if it ever landed

Is there a way for us to pick "latest compatible" instead of "latest" without trying every version?

cc @nkolev92

[nguerrera]

cc @natemcmaster

[nkolev92]

Unfortunately no, there is no way to do that today.
A feature that should address it is NuGet/Home#4071, but it's not actively worked on and I am not aware of the timeline for that.

[dagood]

Filed #927 to track the specific potential workaround of source-building the ASP.NET Core tool packages, if possible.

[natemcmaster]

@dagood is it reasonable to suggest that the latest dotnet-dev-certs package should multitarget netcoreapp2.1 and netcoreapp2.2?

I don't even know if the SDK supports that. @nguerrera @wli3 do you know if you already have issues on dotnet/cli to support multi-targeting global tools?

In the meantime, @omajid try this

dotnet tool install dotnet-dev-certs --version '2.1.*'

[wli3]

@natemcmaster this is supported from start. You can change <TargetFramework>netcoreapp2.1<TargetFramework> to <TargetFrameworks>netcoreapp2.1;netcoreapp2.2<TargetFrameworks>

It will produce both tfms artifact in the same nupkg and nuget will find the most fit one during dotnet tool install

[natemcmaster]

Ok. Then the next step would be to request support for using 2.2 tools with a 2.1 SDK. @dagood @omajid you can do that by opening an issue on https://github.com/aspnet/AspNetCore. I can't promise we'd actually do this in a 2.2 patch, but it doesn't hurt to ask.

[dagood]

Filed a couple more issues:

• In 2.2 tools packages, multitarget 2.2 and 2.1 so latest version is usable with LTS SDK aspnetcore#4613 "In 2.2 tools packages, multitarget 2.2 and 2.1 so latest version is usable with LTS SDK"
• https://github.com/dotnet/cli/issues/10468 "Add 'dotnet tool install' failure potential reason: 'tool requires a runtime that is not installed'"

[crummel]

We believe this is covered by the issues that Davis logged in other repos and there's no source-build work here.