UX improvement: dotnet CLI should automatically restore when necessary
See original GitHub issueError messages which instruct the user to carry out some action can generally be replaced with the action itself. In this case, the error NU1009: The expected lock file doesn't exist. Please run "dotnet restore" to generate a new lock file
and other similar warnings/errors are annoying and it seems they should be replaced with an automatic run of dotnet restore.
Steps to reproduce
dotnet new
dotnet run
Expected behavior
The dotnet
cli recognizes that project.lock.json
is missing or out of date and automatically runs dotnet restore
without prompting the user to do it.
log : The expected lock file doesn't exist. Automatically restoring packages to recreate it.
log : Restoring packages for /home/bburns/projects/dotnettest/project.json...
log : Writing lock file to disk. Path: /home/bburns/projects/dotnettest/project.lock.json
log : /home/bburns/projects/dotnettest/project.json
log : Restore completed in 709ms.
Project dotnettest (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing
Compiling dotnettest for .NETCoreApp,Version=v1.0
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:00.8663525
Hello World!
Actual behavior
bburns@workstation:~/projects/dotnettest$ dotnet run
The current project is not valid because of the following errors:
/home/bburns/projects/dotnettest/project.lock.json(1,0): error NU1009: The expected lock file doesn't exist. Please run "dotnet restore" to generate a new lock file.
Environment data
dotnet --info
output:
.NET Command Line Tools (1.0.0-preview2-003121)
Product Information: Version: 1.0.0-preview2-003121 Commit SHA-1 hash: 1e9d529bc5
Runtime Environment: OS Name: ubuntu OS Version: 16.04 OS Platform: Linux RID: ubuntu.16.04-x64
Issue Analytics
- State:
- Created 7 years ago
- Comments:9 (5 by maintainers)
Top GitHub Comments
@benjamincburns I think you are right. I am re-opening this to see if there is anything at all that we can do that won’t risk causing more trouble than fixing it.
We are tracking this work at https://github.com/dotnet/cli/issues/6105. Closing this one as a dup.