Crash in Blazor app when accessing WebAssembly pages via mDNS (.local) hostname

Question

I a complete noob when it comes to ASP.Net and Blazor, so please be gentle with me...

I have set up the SignalR sample code - as far as I am aware, this is just a template Blazor app - the standard template Home, Counter, Calendar pages (Which are all server-side?) plus a Chat page (Which is WebAssembly)

I have deployed the code to a Raspberry Pi (Running DietPi)

The pi is connected via ethernet to my home network and I can access it via the DNS name dietpi just fine on my windows PC and on my Android phone (Phone connected via wifi to my home network, so it's still connecting to the pi via the ethernet interface)

The pi is also running a wireless hotspot. My use-case is such that what I wish to do at deploy-time is to connect my phone to the pi hotspot and access the app that way (I will be wearing the pi, so I will not be at home). When accessing in this mode, the pi's DNS name is dietpi.local (Rather than just dietpi when it is connected to the lan)

When I access the Blazor site via dietpi.local, the ?Server-side? (Home, Counter, Calendar) pages work fine, however accessing the Chat app (WebAssembly) causes a crash.

Here is a screenshot of the exception - note it says 'Name or service not known (dietpi.local:5000)' The above is when accessing the Chat page via dietpi.local (Which I will need to do in production), but if I access the site from the same device as dietpi, the Chat page does not crash.

Any thoughts?

Answer 1

Hello evilC, 

Thanks for the context. From what you wrote and what’s shown on the Microsoft Q&A page, your Blazor app behaves differently depending on how you reach it. When you hit it as dietpi it works, but when you go to dietpi.local the WebAssembly Chat page crashes with a “Name or service not known (dietpi.local:5000)” error. That message usually means the browser couldn’t resolve the hostname when it was trying to load something.  

Blazor WebAssembly apps load a bunch of files in the browser after the initial HTML is served (the .wasm file, the DLLs, the Blazor boot files, etc.). If any of those resource requests can’t find or resolve the host for the request, the WebAssembly app will fail to start. 

One thing to keep in mind is that hostnames ending in .local are not resolved through normal DNS, they’re usually resolved using multicast DNS (mDNS). That works differently from regular DNS and isn’t guaranteed to work in every client environment or network setup (for example, some routers or clients don’t handle .local names consistently).  

A couple of things worth trying to narrow this down: 

• Try accessing the app by its IP address instead of dietpi.local. If the WebAssembly page loads fine with the IP, that strongly suggests the problem is with the .local name not being resolved properly in the context of those resource requests. 
• Make sure your network is actually resolving dietpi.local in all contexts where the browser is making requests. If mDNS isn’t working reliably for your setup, that would explain why the browser’s requests fail even though other ways of reaching the Pi seem to work. 

If the IP approach works and you still need the app to work under dietpi.local, you could also look at how the app constructs URLs for its files. Blazor uses the <base href="..."> in wwwroot/index.html as the base for all relative URLs, so making sure that base matches the current request or using relative URLs instead of hard-coded paths can sometimes help avoid issues with hostnames. 

Opening your browser’s developer tools and watching the Network tab as you reload the page can also show exactly which requests are failing (e.g., DNS errors vs 404s), which helps confirm whether the problem really is hostname resolution. 

Those aren’t guaranteed solutions for the crash, and this isn’t something has a documented fix for yet, but they are worth checking out. 

  

Hope this helps!