dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.36k stars 9.99k forks source link

Blazor WebAssembly hot reload support broken when changing environment from Development #39269

Open CezaryKlus opened 2 years ago

CezaryKlus commented 2 years ago

Is there an existing issue for this?

Describe the bug

When launching Blazor WASM standalone application via dotnet watch (behind the scenes launching a dev server to host it) hot reload support is broken when host environment is changed to anything else than Development. In the browser's console it reports:

Error: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.AspNetCore.Components.WebAssembly.HotReload.WebAssemblyHotReload.ApplyHotReloadDelta(String moduleIdString, Byte[] metadataDelta, Byte[] ilDeta) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) --- End of stack trace from previous location --- at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.InvokeSynchronously(JSRuntime jsRuntime, DotNetInvocationInfo& callInfo, IDotNetObjectReference objectReference, String argsJson) at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.Invoke(JSRuntime jsRuntime, DotNetInvocationInfo& invocationInfo, String argsJson) at Microsoft.AspNetCore.Components.WebAssembly.Services.DefaultWebAssemblyJSRuntime.InvokeDotNet(String assemblyName, String methodIdentifier, String dotNetObjectId, String argsJson)

Also _framework/blazor-hotreload.js is not loaded and is not fetched (not causing 404 errors).

Related:

35194

37462

Expected Behavior

Hot reload feature should not depend on the environment's name? If it definitely should then please make it bolded in the documentation. Developers are often customizing these names, e.g. Local for the local development machine which breaks the functionality.

Steps To Reproduce

Change ASPNETCORE_ENVIRONMENT in the project's launchSettings.json from Development to anything else.

Exceptions (if any)

Error: System.NullReferenceException: Object reference not set to an instance of an object.

.NET Version

6.0.100

Anything else?

.NET SDK (reflecting any global.json): Version: 6.0.100 Commit: 9e8b04bbff

Runtime Environment: OS Name: Windows OS Version: 10.0.19044 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support): Version: 6.0.1 Commit: 3a25a7f1cc

.NET SDKs installed: 3.1.416 [C:\Program Files\dotnet\sdk] 6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

ghost commented 2 years ago

Thanks for contacting us. We're moving this issue to the .NET 7 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.

thierryrama commented 2 years ago

I can confirm that this is an issue with my project too. Using custom environment name Local for development and getting "Error: System.NullReferenceException: Object reference not set to an instance of an object." when hot reloading from Visual Studio Version 17.0.0 and dotnet watch (version 6.0.100).

Oneguy23 commented 2 years ago

Confirming same issue here, when ASPNETCORE_ENVIRONMENT is Local. VS 17.1.0. Changing ASPNETCORE_ENVIRONMENT to Development "fixes" the issue, but would prefer not to have to make that switch.

meronz commented 2 years ago

Same here. In some scenarios it is useful to differentiate between multiple development environments.

lonix1 commented 2 years ago

I think I read somewhere that hot reload doesn't work when any non-default environment variables or switches are used. Which is confirmed by basic testing - when you change any option it stops working, when you add switches it stops working. But if you keep the defaults (which includes the development environment) then it works.

Also debugging + hot reload don't work at the same time.

I hoped it would be fixed in the latest v6.0.300 (from a few days ago), but unfortunately I still get the issue.

igotinfected commented 2 years ago

Same issue still present here as well, though my issue is more related to #35194. The main issue being that when you define a different base path, the local environment stops working properly.

Here's a look at the folder structure:

image

Blazor expects blazor-hotreload to be at \webapps\xxx\_framework\blaz... given the following code:

image

Here's my launch settings:

"profiles": {
    "xxx.App": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/webapps/xxx/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "applicationUrl": "https://localhost:5001;http://localhost:5000",
      "launchUrl": "webapps/xxx",
      "commandLineArgs": "--pathbase=/webapps/xxx",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
andylegear commented 1 year ago

Confirming same issue here, when ASPNETCORE_ENVIRONMENT is Local. VS 17.1.0. Changing ASPNETCORE_ENVIRONMENT to Development "fixes" the issue, but would prefer not to have to make that switch.

I experienced this exact issue. Confirming that the switch of the ASPNETCORE_ENVIRONMENT back to Development in my profile fixed the problem

ghost commented 1 year ago

To learn more about what this message means, what to expect next, and how this issue will be handled you can read our Triage Process document. We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. 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 work.

JeroMiya commented 2 days ago

Not sure if it's related to this issue or a new issue, but I'm seeing blazor debugging is now broken completely in 8.0.8 (versions after this up to at least 8.0.10 are broken due to a separate issue) for all launch profiles where the ASPNETCORE_ENVIRONMENT is set to anything other than Development. I see the in the log that lots of requests are being made to the websocket proxy but they're all getting 404s.

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET https://localhost/esign/_framework/debug/ws-proxy?browser=ws%3A%2F%2F127.0.0.1%3A53990%2Fdevtools%2Fbrowser%2F2cfff964-3ff3-44fa-af59-768fed509891 - - -
trce: Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware[2]
      All hosts are allowed.
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1001]
      1 candidate(s) found for the request path '/_framework/debug/ws-proxy'
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]
      Endpoint '(null)' with route pattern '/_framework/{*path}' is valid for the request path '/_framework/debug/ws-proxy'
dbug: Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware[1]
      Request matched endpoint '(null)'
trce: Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware[8]
      The endpoint does not specify the IRequestSizeLimitMetadata.
dbug: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[15]
      Static files was skipped as the request already matched an endpoint.
dbug: Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler[9]
      AuthenticationScheme: Cookies was not authenticated.
dbug: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[15]
      Static files was skipped as the request already matched an endpoint.
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
      Executing endpoint 'Microsoft.AspNetCore.Routing.RouteEndpoint'
dbug: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[4]
      The request path /_framework/debug/ws-proxy does not match a supported file type
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint 'Microsoft.AspNetCore.Routing.RouteEndpoint'
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[9]
      Connection id "0HN7ETAF5E43F" completed keep alive response.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[6]
      Connection id "0HN7ETAF5E43F" received FIN.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET https://localhost/esign/_framework/debug/ws-proxy?browser=ws%3A%2F%2F127.0.0.1%3A53990%2Fdevtools%2Fbrowser%2F2cfff964-3ff3-44fa-af59-768fed509891 - 404 0 - 20.0468ms
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
      Connection id "0HN7ETAF5E43F" sending FIN because: "The Socket transport's send loop completed gracefully."
info: Microsoft.AspNetCore.Hosting.Diagnostics[16]
      Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://localhost/esign/_framework/debug/ws-proxy, Response status code: 404
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[10]
      Connection id "0HN7ETAF5E43F" disconnecting.