dotnet build / run taking too long due to enforced default restore
See original GitHub issueSteps to reproduce
- Create a new empty web project.
- Run dotnet build
- Run dotnet run
- Compared to 1.x, it takes around 2-4x times than before.
- Run the same commands with --no-restore . Notice it’s faster.
Expected behavior
- I am the developer. I am solely responsible for running dotnet restore in case I have missing packages.
- Commands should run with --no-restore as default, or at least have a global flag (or similar to .npmrc) to set it up.
Actual behavior
- dotnet restore is being enforced prior to build/run, so development isn’t as streamlined as it used to be, it’s slow. SLOW.
Environment data
dotnet --info
output:
.NET Command Line Tools (2.0.0)
Product Information: Version: 2.0.0 Commit SHA-1 hash: cdcd1928c9
Runtime Environment: OS Name: Mac OS X OS Version: 10.12 OS Platform: Darwin RID: osx.10.12-x64 Base Path: /usr/local/share/dotnet/sdk/2.0.0/
Microsoft .NET Core Shared Framework Host
Version : 2.0.0 Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (7 by maintainers)
Top Results From Across the Web
dotnet core 2 long build time because of long restore time
I noticed that building in dotnet core 2 seemed a lot slower. But the timing after the build always showed 'only' 15 seconds....
Read more >Troubleshoot .NET tool usage issues
Discover the common issues when running .NET tools and possible solutions.
Read more >Dotnet task build much slower than VS build task
I started noticing significantly better "dotnet restore" timing after point 1. Build time was back to normal after point 3.
Read more >DotNet core slow restore : r/docker
recently I'm facing a increase on the build time (+5 minutes from initial ~1 minute) when doing . There was no major changes...
Read more >.NET SDK Support
The default for most projects is Debug , but you can override the build configuration ... Doesn't execute an implicit restore when running...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The build takes time as well as the restore. In my opinion,
dotnet run
should by default not do a build nor a restore, or there should be some other first class way to simply run (without needing parameters). Since there is no executable produced, I have no alternative but to usedotnet run
today:I created a Makefile for my project that, in the target “run” uses dotnet path/to/dll if the target dll is newer than the source files. Otherwise, it runs dotnet run. When there is no need to build, execution of my program takes 0.2 seconds. In the same conditions, dotnet run --no-build --no-restore takes 0.8 seconds. This makes no sense to me. In the same conditions (executable not older than source), dotnet run takes 2.3 seconds. Which makes even less sense to me. It’s not a matter of efficiency but a matter of not doing anything when the thing is already built. What’s wrong with such a simple behaviour?