aspnetcore icon indicating copy to clipboard operation
aspnetcore copied to clipboard

Debugging Blazor Webassembly running in a dev container

Open NCC1701M opened this issue 3 years ago • 10 comments

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 #27766

NCC1701M avatar Oct 14 '21 19:10 NCC1701M

@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

javiercn avatar Oct 18 '21 10:10 javiercn

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.

ghost avatar Oct 18 '21 10:10 ghost

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 #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 #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.

NCC1701M avatar Oct 19 '21 09:10 NCC1701M

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.

ghost avatar Nov 11 '21 17:11 ghost

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

JBBianchi avatar Mar 07 '22 09:03 JBBianchi

  • 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.

braidenstiller avatar Mar 18 '22 06:03 braidenstiller

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.

kot-pilot avatar Aug 07 '22 18:08 kot-pilot

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?

Peluko avatar Sep 01 '22 09:09 Peluko

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.

NCC1701M avatar Sep 01 '22 10:09 NCC1701M

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.

ghost avatar Oct 13 '22 17:10 ghost

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

mustafacagataytulun avatar May 29 '23 14:05 mustafacagataytulun

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.

ghost avatar Jun 29 '23 22:06 ghost

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

holtalanm avatar Jul 20 '23 02:07 holtalanm

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

Robertblazor avatar Jul 26 '23 15:07 Robertblazor

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 :-(

dazinator avatar Sep 28 '23 10:09 dazinator

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

davhdavh avatar Oct 09 '23 02:10 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

davhdavh avatar Oct 09 '23 05:10 davhdavh

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

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

rrmistry avatar Dec 09 '23 21:12 rrmistry

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.

ghost avatar Dec 12 '23 17:12 ghost

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

danroth27 avatar Jan 25 '24 07:01 danroth27

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

Peluko avatar Feb 17 '24 18:02 Peluko