The code, compile, reload cycle isn't necessary, it's just the way things are. We can make coding more interactive. Imagine a default workflow where coding is manipulating the code in a running application! That could extend beyond development, but for now at least in development.
In working on projects that use both backend builds (.NET Core) and front end builds (Webpack), I wish we could have a better development experience on the backend.
Webpack's HMR allows me to change code and webpack's dev server pushes those changes into the running application by replacing code, styles, html, etc. Net effect, I can make changes and instantly see the impact without losing application state, and without waiting 10+ seconds for a compilation and reload.
On the backend, as the code and dependencies grow, the time to recompile grows. Add to that: time to restart the app and possibly reload state. This becomes a huge time sink for making simple changes.
We have Edit and Continue functionality in Visual Studio, would it be possible to extract that out and put it into the SDK tooling? Maybe a dotnet edit-and-continue or dotnet hot or dotnet watch --hot?
This would then work cross-platform and with any IDE. And best of all, I can spin up a Docker container with the SDK and my web app and that's all I need to develop anywhere.
I know work is being done to improve the build times in general, but some of that build time wouldn't be a big deal if we had hot swap for development because then slow build times are just on initial build and on build servers.
Behavior wise, here are a few thoughts:
+100 for this
cc @tmat
While I think the idea of having a watcher that performs EnC like VS is very intriguing, it's not really something that we'd implement in this repo. So I'll close this. Conceptually, I could imagine it getting integrated in to dotnet watch: https://github.com/aspnet/DotNetTools, but it is probably a huge undertaking.
It would be nice to have this kind of feature. It's indeed a huge undertaking. I'd recommend to file a feature request in VS user voice.
I'm not sure dotnet-watch is the right place either. dotnet-watch is a layer above dotnet-run, so if this is something dotnet-run could support, then dotnet-watch could too, but not the other way around.
Most helpful comment
+100 for this