[Discussion] dotnet-watch and dotnet-user-secrets will move into the .NET Core CLI in 2.1.300

[natemcmaster]

This is a discussion issue for aspnet/Announcements#290.

---

Update Feb. 28: Some clarification. This announcement was in regards to 2.1.300-preview2 versions of the CLI and up.

In 2.1.300-preview1, the following ASP.NET Core command line tools can be installed as a global command.

• dotnet watch
• dotnet user-secrets
• dotnet sql-cache

In 2.1 Preview 1, these commands are not pre-installed. You must use the dotnet install tool command to acquire them.

dotnet install tool dotnet-watch --global --version 2.1.0-preview1-final
dotnet install tool dotnet-dev-certs --global --version 2.1.0-preview1-final
dotnet install tool dotnet-user-secrets --global --version 2.1.0-preview1-final

If you have an existing project with a DotNetCliToolReference to the packages below, you must remove the DotNetCliToolReference in order to try the global version of the command.

• Microsoft.DotNet.Watcher.Tools (aka dotnet-watch)
• Microsoft.Extensions.SecretManager.Tools (aka dotnet-user-secrets)
• Microsoft.Extensions.Caching.SqlConfig.Tools (aka dotnet-sql-cache)

Prior to this release, these commands were only available if added to the MSBuild project as a DotNetCliToolReference and when executing "dotnet" in the project directory.
Once installed globally, the commands are available from any project directory.

Note: Using dotnet install tool will only apply to 2.1 Preview 1. Before we release the RTM version of 2.1, these will become built-in commands in the .NET Core CLI.
You won't need to use DotNetCliToolReference or dotnet install tool to acquire these commands. This is what aspnet/Announcements#290 was intended to communicate.

[natemcmaster]

@shanselman please use this thread instead of aspnet/Announcements#290 for discussion so we don't keep spamming subscribers on aspnet/Announcements.

To answer your question aspnet/Announcements#290 (comment), for 2.1.300-preview1, dotnet-watch is installed like this:

dotnet install tool -g dotnet-watch --version 2.1.0-preview1-final

This won't be necessary after preview1.

[dfederm]

@natemcmaster I think what @shanselman is getting at is that while it's great that it's no longer needed, the people who don't know that these tools are built in now will just see it as broken.

It seems like it should provide a friendly error explaining that it's no longer needed because it's now built-in rather than failing with some obscure error.

[chilas]

@natemcmaster @dfederm Maybe leaving a message for the user informing them that it's already installed won't be a bad idea.

[natemcmaster]

Thanks for the feedback. I agree - the error message is not very helpful in the situation @shanselman ran into. I've opened https://github.com/dotnet/cli/issues/8698 to provide a better error message for users.

It seems like it should provide a friendly error explaining that it's no longer needed

Good point. That's a separate situation we had not thought of. I've opened dotnet/aspnetcore#2911 to see if we can provide some kind of message during restore to indicate that a DotNetCliToolReference is no longer needed.

[natemcmaster]

You should see an obsolete message in preview2 when you have a DotNetCliToolReference to a tool that is now bundled in the SDK. cref dotnet/sdk#2064

[qbikez]

@natemcmaster What's the rationale behind bundling these tools with .net CLI? Can you provide some links to discussion, Community Standup, etc. regarding this decision?

[natemcmaster]

I don't think any of that discussion was out in the open. The gist of it is that the ASP.NET Core runtime is bundled with the SDK, so we thought it was also important to bundle tools for that runtime.

We also think the global tools are a better model than the DotNetCliToolReference; DotNetCliToolReference required editing every .csproj that uses aspnetcore, the commands were only available in the project directory, and it made dotnet restore slower.

cc @danroth27 @DamianEdwards if you want to share more thoughts.

[natemcmaster]

Closing as this issue as the 2.1.300 SDK has been released and includes this change. Feel free to continue discussion if you have more questions.

[t123yh]

$ dotnet --version
2.1.301
$ dotnet ef
Cannot find command 'dotnet ef', please run the following command to install

dotnet tool install --global dotnet-ef

I'm still unable to use dotnet ef in 2.1.301. What's the problem? I'm on Manjaro Linux 17.1.10.

[natemcmaster]

I don't know much about Manjaro Linux 17.1.10. How did you install dotnet on your machine? Can you share the output of dotnet --info?

[t123yh]

@natemcmaster Manjaro Linux uses package repository from Arch Linux, and I installed dotnet-sdk with pacman.
The following is the output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.301
 Commit:    59524873d6

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /opt/dotnet/sdk/2.1.301/

Host (useful for support):
  Version: 2.1.1
  Commit:  6985b9f684

.NET Core SDKs installed:
  2.1.301 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.1 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.1 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.1 [/opt/dotnet/shared/Microsoft.NETCore.App]

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

[natemcmaster]

Arch Linux support is community maintained. From what I can tell from the dotnet-sdk package definition the package contents do not contain dotnet-ef. I'm not sure why the Arch Linux maintainer decided to remove it, or if this was unintentional. Try downloading the Linux x64 SDK binaries (comes in a .tar.gz) from https://www.microsoft.com/net/download/linux instead and give that a try.

Side note: you are also likely running into these error even after running dotnet tool install because of a known issue in the .NET Core SDK on Linux. https://github.com/dotnet/cli/issues/9114 This happens when your .NET Core SDK is installed into a non-default location (as the Arch Linux package is doing). You can workaround this by adding this to your .bashrc file.

export DOTNET_ROOT=$(dirname $(realpath $(which dotnet)))

[alucryd]

I didn't remove anything, if it's not there, it's because the source-build repo does not bundle it.

[t123yh]

@natemcmaster @alucryd Could you please kindly solve this problem? It gives me much pain not able to use dotnet ef. I would appreciate it if the problem can be solved.

[natemcmaster]

@t123yh can you be more specific about which problem you are referring to? I would recommending opening an issue on https://github.com/aspnet/EntityFrameworkCore if you are still having issues with dotnet ef.