"dotnet run" went from 4 seconds to 45 seconds to lauch project
See original GitHub issueLooks like dotnet is scanning the complete directory rather than specifying a ‘launch’ .cs file and following dependencies used from that file. Equally, it would be good to be able to specify different launch commands under one git repo to manage different process types, for example:
> dotnet run worker_imageprocessor.cs
> dotnet run kestel_server.cs
Steps to reproduce
Working on a small app, c# backend, react frontend. Used ‘create-react-app & npm install’ to create a folder ‘frontend’ under project directory (common directory structure in nodejs projects)
Expected behavior
Expected this would have no impact on dotnet cli as the frontend folder has no files related to the backend build process, however.
Actual behaviour
It caused every dotnet run to take 10x longer.
Environment data
.NET Command Line Tools (2.0.0)
Product Information: Version: 2.0.0 Commit SHA-1 hash: cdcd1928c9
Runtime Environment: OS Name: Windows OS Version: 10.0.15063 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\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:5 (5 by maintainers)
Try adding excludes to
.csproj
for node_modules https://github.com/dotnet/cli/issues/7525#issuecomment-324998276e.g.
The fix I described above is now checked in. This should improve performance of
dotnet run --no-build
dramatically and reduce the overall time of justdotnet run
by a considerable amount when run in directories containing a large set of files, even withoutDefaultItemExcludes
set.I still recommend setting that property to exclude unnecessary directories from being globbed for the build, though.
Thank you for reporting this issue to us, @khowling.