aspnetcore
aspnetcore copied to clipboard
Hot reload not enabled if dotnet CLI initialized with arguments
I want to be able to run dotnet watch run --urls="https://localhost:7005" to start my application server at a specific port and have hot reload enabled.
However, hot reload is not enabled if dotnet watch is invoked with non-default parameters.
Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
We are using pathbase in our blazor development and need to pass it in as part of the dotnet command. Are there any workarounds for this at the moment?
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Workaround is to set the ASPNETCORE_URLS environment variable instead of passing --urls. But yes, please fix this!
Any progress on this? It is kind of sad that you have to hard code any app parameters in the app to use dotnet watch. Why not just forward parameters after -- to the app as with dotnet run.
That's a few hours wasted for me before I found this issue... major pain. We se a few env vars in launchSettings.json for local development and dotnet watch run did not select a launch profile (I'm pretty sure it used to do that!) so tried using --launch-profile flag and then hot reload died 🤦♂️!
Resorted to a .ps1 file that sets the env vars before dotnet watch run and then running that.
Hope you can get this fixed soon!
Any news on this?
Same here. I wasted hours before finding this issue. I wanted to select a launch profile with --launch-profile argument or using --urls and hot reload died :(
I am having the same issue with running a MonoGame game :(
@tmat leaving this up to you to prioritize.
Chiming in as I'm also experiencing this issue, and it's causing devs to have to wait for a 2-minute build time + ~30-60 seconds to navigate back to the relevant section in the app, for every change they make. Not very productive, as you might imagine. We run various other dev watchers too, which we don't want the VS build to handle in dev mode (webpack etc).
.Net 6 with SDK 6.0.8
I'm using this command:
dotnet watch run --no-restore --launch-profile service-hosts -v n -c Debug-CustomerName
With the following launch profile:
"service-hosts": {
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
"launchBrowser": false,
"dotnetRunMessages": "true",
"applicationUrl": "https://localhost:12345",
"sslPort": 12345
}
And the following env variables:
$Env:ASPNETCORE_ENVIRONMENT = $dotNetEnv;
$Env:ASPNETCORE_URLS = "https://localhost:$($app.port)";
$Env:DOTNET_WATCH_SUPPRESS_EMOJIS = "true";
bump
Is there any workaround for this issue?
I can also see that it has been moved from .net 7 planning to do .net 8 planning...
Just upgraded to .net 7 and was disappointed to discover that it still doesn't work as expected.