"dotnet run" went from 4 seconds to 45 seconds to lauch project

Looks 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

[benaadams]

Try adding excludes to .csproj for node_modules https://github.com/dotnet/cli/issues/7525#issuecomment-324998276

e.g.

<PropertyGroup>
  <DefaultItemExcludes>node_modules/**;$(DefaultItemExcludes)</DefaultItemExcludes>
</PropertyGroup>

[peterhuene]

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 just dotnet run by a considerable amount when run in directories containing a large set of files, even without DefaultItemExcludes 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.