Debugging Blazor Webassembly running in a dev container

[NCC1701M]

When will it be possible to debug blazor standalone webassembly apps that are running in a dev container.

For further information please have a look at dotnet/aspnetcore#27766

[javiercn]

@NCC1701M thanks for contacting us.

This is still not possible today. I'm going to put it in our backlog for consideration for 7.0

[ghost]

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.

[NCC1701M]

This is still not possible today. I'm going to put it in our backlog for consideration for 7.0

Well that doesn't sound well. The issue dotnet/aspnetcore#27766 is nearly a year old. The plans were to ship this with .Net 6 and now it might be in 7. As I already mentioned in dotnet/aspnetcore#27766 this will be a crucial point for teams using dev containers and considering to switch to blazor web assembly. This could stop them from switching.

In our case, unfortunately, we will not switch to Blazor WASM now but continue to work with Angular.

[ghost]

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.

[JBBianchi]

Is there any manual solution/workaround for this in the meanwhile?

[braidenstiller]

• 1 for the manual solution workaround or for when this gets released.

Having to swap between docker environment and running on the machine launch profiles gets tedious when debugging.

[kot-pilot]

Is there any manual solution/workaround for this in the meanwhile?

I have started developing pet-project which will be using blazor webassembly standalone as UI and several asp.net core backend services for trying microservice architecture. Adding docker orchestration support for asp.net core apps seems to be easy with several clicks in visual studio and all these services can be run and be debugged with running 'docker-compose' startup project. So for being able to run and debug blazor UI + all asp.net core microservices at the same time in dev environment I ended up using 'multiple startup project' visual studio feature. So there I choose to startup my blazor ui and docker-compose projects. This seems to be temporary workaround to spin all stuff at the same time and debug it, while there is no possibility to also debug web assembly standalone app in container.

[Peluko]

It's a shame that Blazor Webassembly doesn't contribute to this success:

VS Code Emerges As Remote Development Superstar

I see that it's on .Net 7 backlog, but it also was scheduled for .Net 6. Will it do on .Net 7?

Any manual workarounds?

[NCC1701M]

It's a shame that Blazor Webassembly doesn't contribute to this success:

I agree totally... Especially for a web development framework which should be really independent of the dev environment, remote debugging should be supported natively.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[mustafacagataytulun]

Dear msftbot,

I think this is not a very rare and low-impact issue. On the contrary, running a Blazor WebAssembly application in a containerized development environment is a common scenario, especially with a microservice architecture.

Currently, we are trying to use logging to browser console to understand what is happening in our application at runtime.

Sincerely yours

[ghost]

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.

[holtalanm]

So frustrating to see issue after issue mentioning this for over 3 years and still nothing for debugging WASM from within the WSL.

[Robertblazor]

I will keep an eye on this, inform me if there are any updates.

[dazinator]

There is a nice description of the problem here: https://stackoverflow.com/questions/59228315/debug-blazor-wasm-using-visual-studio-container-tools

Still waiting for this :-(

[davhdavh]

It would be really nice if the staticwebassets.json problem could be solved soon

[davhdavh]

Found the bug...
Microsoft.VisualStudio.Containers.Tools.Common.PathUtilities.TryGetContainerPath
has this line:

string str1 = volumeMappings.Keys.FirstOrDefault<string>((Func<string, bool>) (key => hostPath.StartsWith(PathUtilities.RemoveTrailingSeparator(key), StringComparison.OrdinalIgnoreCase)));

and volumeMappings contains [c:\solution\project -> /app, c:\solution -> /src], so when it sees reference to c:\solution\project.client it will replace that with first c:\solution\project -> /app and thus you end up with /app/client, instead of the correct /src/project.client
@mkArtakMSFT

[rrmistry]

What about debugging client-side Blazor WASM app from within a dev container?

I posted questions here but no viable solutions / workarounds yet:

• How to debug Client side Razor code for Blazor WASM app when it is hosted in a Kubernetes Pod?
• How to debug Blazor WASM client side from within a Dev Container?

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[danroth27]

@DamianEdwards How much is .NET Aspire impacted by this? Presumably you can't currently debug you Blazor client code in a .NET Aspire app?

[Peluko]

I hope that this will be addressed now that part of MS's .NET 9 vision is 'Tools for Cloud-Native Developers'...

[TalonZA]

This is not only a WASM issue. I am also looking for Blazor Server Debugging. Is it related or should I be opening a separate feature request and also waiting about 4 years for nothing to happen?

[drungrin]

Use an X server like VcXsrv or Xming on your host, set the DISPLAY environment variable in your dev container (Docker or WSL) to point to that server (for example, DISPLAY=host.docker.internal:0), and install Chrome (or another GUI browser) inside the container. When you run or debug your ASP.NET Core app (e.g., via dotnet run), the browser will open on your local desktop through the X server, allowing you to interact with the application’s UI as if it were running directly on your host.

On cloud, use dev tunnels from visual studio, or any other similar technology.

[dazinator]

Use an X server like VcXsrv or Xming on your host, set the DISPLAY environment variable in your dev container (Docker or WSL) to point to that server (for example, DISPLAY=host.docker.internal:0), and install Chrome (or another GUI browser) inside the container. When you run or debug your ASP.NET Core app (e.g., via dotnet run), the browser will open on your local desktop through the X server, allowing you to interact with the application’s UI as if it were running directly on your host.

On cloud, use dev tunnels from visual studio, or any other similar technology.

Not to detract from your solution, but i'd rather our IDE's solved common debugging experiences for us, its their bread and butter. None of that VcXsrv stuff is stuff I want to burden my team with.

[NCC1701M]

Not to detract from your solution, but i'd rather our IDE's solved common debugging experiences for us, its their bread and butter. None of that VcXsrv stuff is stuff I want to burden my team with.

I agree, this might be a workaround but only for enthusiasts not for daily work. There has to be a solution and it has to come from the aspnetcore respectively the blazor wasm team.

[lewing]

With the new mono debugger, the integration should start the proxy which would solve the underlying issue here. @ilonatommy please test this with a recent VS preview and double check with @thaystg

[javiercn]

@lewing does this mean that we can simply remove the code that launches the debugger from the dev server and the hosted template?

I can see this working for VS and VS Code. Does it need to work if you want to debug from dotnet run? (I don't necessarily think so, but if it needed to, this could be a separate tool/command that you run from the CLI to start the proxy).

[drungrin]

Use an X server like VcXsrv or Xming on your host, set the DISPLAY environment variable in your dev container (Docker or WSL) to point to that server (for example, DISPLAY=host.docker.internal:0), and install Chrome (or another GUI browser) inside the container. When you run or debug your ASP.NET Core app (e.g., via dotnet run), the browser will open on your local desktop through the X server, allowing you to interact with the application’s UI as if it were running directly on your host.
On cloud, use dev tunnels from visual studio, or any other similar technology.

Not to detract from your solution, but i'd rather our IDE's solved common debugging experiences for us, its their bread and butter. None of that VcXsrv stuff is stuff I want to burden my team with.

I totally get your point—ideally, IDEs should handle these common debugging workflows seamlessly. But until they do, we often have to rely on workarounds to get things working efficiently. The X server approach is just one way to bridge the gap when debugging GUI applications inside containers.

That said, if your team wants a smoother experience without setting up X servers, using dev tunnels in Visual Studio or similar tools might be a more user-friendly alternative. These allow you to access your containerized app in a local browser without extra setup.

Hopefully, IDEs improve in this area, but for now, it’s about finding the best balance between convenience and functionality. Happy to hear if you have a better approach!

[ilonatommy]

I am not able to reproduce the issue, I am using Version 17.14.0 Preview 2.0 [35803.257.main], created a net9 blazor wasm app with docker support added by VS. I am able to break on client's code running with and without orchestration, regardless of the value of previewFeatures.debuggerNewMonoDebugEngine.
@drungrin, I understand that in your case, you are still seeing the problem. What VS version are you using?

Edit:
the important fact here might be that the container is configured by VS. I can see that in the reproduction I made, it already has important bindings added by default:

"HostConfig": {
		"Binds": [
                       ...
			"C:\\Users\\user\\vsdbg\\vs2017u5:/remote_debugger:rw",
                       ...
                ]
        },
...
"Mounts": [
	{
		"Type": "bind",
		"Source": "C:\\Users\\user\\vsdbg\\vs2017u5",
		"Destination": "/remote_debugger",
		"Mode": "rw",
		"RW": true,
		"Propagation": "rprivate"
	},

[NCC1701M]

@ilonatommy The config you've posted seems like I need to use

1. Windows
2. Visual Studio

I use neither. I'm developing in a container using VSCode on a Linux machine.

[ilonatommy]

@thaystg, I cannot find a working solution for VSCode.

Reproduction steps:

1. 9.0.200-preview.0.25057.12 dotnet new blazor --interactivity WebAssembly
2. Installing Docker extension
3. Ctrl+Shift+P to open the Command Palette, search for Docker: Add Docker Files to Workspace (equivalent of VS's Add -> Docker Support) with .NET: ASP.NET Core, server project, Linux OS, with docker compose.
4. Set the breakpoint in BlazorApp.Client\Pages\Counter.razor , use debugging tools to debug -> breakpoint not hit.

Inspecting the container we can see a bit different volumes information than in VS:

• HostConfig binding is null, even though in docker-compose.debug.yml we have

    volumes:
      - ~/.vsdbg:/remote_debugger:rw

Is it the problem with relativity of the path? VS uses absolute path:

volumes:
      - C:\Users\user\source\repos\BlazorApp1\BlazorApp1\BlazorApp1:/app:rw
      - C:\Users\user\source\repos\BlazorApp1:/src:rw
      - C:\Users\user\vsdbg\vs2017u5:/remote_debugger:rw

• Mount of remote debugger has different rights:

VS:
{
	"Type": "bind",
	"Source": "C:\\Users\\user\\vsdbg\\vs2017u5",
	"Destination": "/remote_debugger",
	"Mode": "rw",
	"RW": true,
	"Propagation": "rprivate"
}

VSCode:

{
	"Type": "bind",
	"Source": "C:\\Users\\user\\.vsdbg",
	"Target": "/remote_debugger",
	"ReadOnly": true
}

It looks like a missing bit in the debugging extension.

[dotnet-policy-service]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.