aspnetcore
aspnetcore copied to clipboard
Debugging Blazor Webassembly running in a dev container
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 thanks for contacting us.
This is still not possible today. I'm going to put it in our backlog for consideration for 7.0
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.
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.
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.
Is there any manual solution/workaround for this in the meanwhile?
- 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.
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.
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?
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.
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.
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
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.
So frustrating to see issue after issue mentioning this for over 3 years and still nothing for debugging WASM from within the WSL.
I will keep an eye on this, inform me if there are any updates.
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 :-(
It would be really nice if the staticwebassets.json problem could be solved soon
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
What about debugging client-side Blazor WASM app from within a dev container?
I posted questions here but no viable solutions / workarounds yet:
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.
@DamianEdwards How much is .NET Aspire impacted by this? Presumably you can't currently debug you Blazor client code in a .NET Aspire app?
I hope that this will be addressed now that part of MS's .NET 9 vision is 'Tools for Cloud-Native Developers'...