0
votes

I have an ASP.NET Core 5 project that as the main function runs a typical ASP.NET web project. So typically I start it with dotnet watch run and the server runs in the background continuously. But I'm also trying to add a way to execute console commands to the same executable, which reuse the code from the server version but don't start the actual WebHost from ASP.NET. The command line version should be able to run either with the server version already running, or entirely standalone.

The problem now is that I'm quite obviously doing something that dotnet run wasn't meant for, because the build is extremely flaky and fails quite often with unhelpful errors (e.g. file access errors, . It does make sense that running dotnet run again while it's still running in the background isn't a supported case, so I'm trying to find a different way to do this.

The whole thing runs inside Docker, though this probably doesn't change anything for my specific problem. I'm using VS Code, so Visual Studio specific solutions would not work for me, it must run with the dotnet CLI alone.

What I want to do is to have a dotnet watch run in the background during development, and a way to just execute the binary it built separately without triggering a simultaneous build that leads to problems. At least as far as I can tell this should avoid the issues I've been running into, if I'm wrong here and running simultaneous dotnet run or dotnet watch run should not cause build issues, please correct me here. I assume that running a separate dotnet build would run into the same issues, and I could not see anything in the dotnet CLI documentation that would fit my use case.

How can I safely run my project in development a second time while it is still running via dotnet watch run in the background?

1
Build both then run? dotnet build dotnet run --no-build - Jeremy Lakeman

1 Answers

0
votes

A quick workaround is to use different build configurations (i.e. dotnet watch run -c Debug and dotnet run -c Release). If you haven't overridden the default output directory (./bin/<configuration>/<framework>/), you will be effectively using two compiled versions of the application, avoiding those 'flaky builds'.

You could also create your own build configuration for this purpose (i.e. dotnet run -c My_Debug) and configure it to have 'debug' properties, avoiding having to use the default Release configuration.