victorhuangwq
commented
12 months ago @oggy22 could you take a look at this feature request to see if it is a reasonable/feasible feature request? If so, we can track it in our backlog.
Open softworkz opened 12 months ago
victorhuangwq
commented
12 months ago @oggy22 could you take a look at this feature request to see if it is a reasonable/feasible feature request? If so, we can track it in our backlog.
softworkz
commented
11 months ago @oggy22 - Reasonable?
oggy22
commented
11 months ago @softworkz if I understand correctly you want to be able to debug Javascript files when running WebView2 apps including hot reloads? Your debugging experience, within VS should be seamless from native code (or dotnet) to Javascript? That scenario works just fine for ASP.NET but doesn't work for WebView2?
softworkz
commented
11 months ago All correct. Maybe it works with WebView2 when the content is served from an ASP.NET server, but it doesn't work in other scenarios, like when WebView2 content is coming from html/js files installed with the application, which is probably the most typical case for WebView2 apps.
Here are a view references to BrowserLink:
BrowserLink is a good starting point, because it already does the things which are needed, just that it's tied to ASP.NET core which it uses to communicate with the browser. BrowserLink includes two parts:
What needs to be done differently is the communication between inside and outside without ASP.NET
softworkz
commented
11 months ago I don't know who is in charge in the ASP.NET team, but @madskristensen has done a lot around BrowserLink in his extensions, maybe he has some additional pointers.
oggy22
commented
11 months ago To me it sounds more like VS Debugger team ask, but it is possible that we may be involved to some extent as well. Can you ask their team? I also have not much idea how much work that would involve. I am just guessing that in the best case it would be tweaking few things in the VS debugger to attach to, get symbols for JS files etc, but in worst case scanario it may involve significat work on both VS debugger and our side.
Just curious what browsers asp.net scenario works well? Is it only Edge?
softworkz
commented
11 months ago To me it sounds more like VS Debugger team ask, but it is possible that we may be involved to some extent as well. Can you ask their team?
While they might be involved, I believe that this is something for which the initiative can only originate from the WebView2 team, because debugging WebView2 JavaScript simultaneously to the application code is a scenario which is primarily specific/useful for applications using WebView2. Besides debugging it will probably also require a small change to the project system. But none of those will have a reason to want that. The only team with stakes in the subject is yours, the WebView team.
As I've seen that enthusiasm is rather moderate (or the right people haven't seen it yet), I took some time to get a bit deeper into the subject and see how far I can get.
A major problem in getting this to work is a rather general one: Debugging of both Script and Managed code at the same time is contradictive and not supported from the debugger side. Whereas "at the same time" is not quire accurate. It's actually about the process: A process to which script debugging is attached cannot have managed code debugging and vice versa. The project systems (latest ones and older ones) reflect that by allowing to choose only either one or the other for debugging.
But well - actually the script debugger doesn't need to attach to the project running the managed code. It needs to interact with a browser or a WebView's contents which is running in a separate process (like msedge.exe) and the script debugger doesn't even attach to it, it interacts through some intermediate proxies or bridges, so it would be perfectly possible to debug both in a single project, just the tooling for most project types doesn't support it.
As of now, there's - to my knowledge - only a single exception of project types which support debugging both at the same time: Asp.NET projects. (in this case, , a browser is launched which can be debugged at the same time ahs the backend code. This doesn't help here, because Asp.Net is not a UI application where you could use a Webview.
Also, we cannot launch a browser since the content must be shown in the WebView.
So far we've been talking about what can be done in a single project. Visual Studio of course supports debugging multiple projects at the same time, and so I went into this direction.
I created a new project and put the Html/JS code into this project and made the WebView2 use it directly from there (file:/// urls). But there's the next problem:
I could have sworn that it was possible in earlier VS versions (or older project systems) to debug projects in a way that the debugger gets attached automatically when loaded (or on debug start), but it seems to be gone (or I couldn't find it). All the debugging options (launchSettings.json) are for launching a project in various ways but nowhere seemed to be a way to do this; I had tried various project types and was about to give up - even though the debugger itself does support attaching, and even to a WebView2.
How did I know this? Because the script debugger in Visual Studio has recently been replaced...by....
The debugger from VS Code, which can be found here: https://github.com/microsoft/vscode-js-debug
While that's not only kind of embarrassing per se for the flagship product to take features from the little brother - the integration into VS (Microsoft.VisualStudio.JavaScript.Diagnostics.JSDebugger) is quite limited. Most of the config options are unavailable and it also doesn't support attach or at least it's not documented afaik).): VSCode uses launch.json and VS launchSettings.json, both incompatible to each other.
Eventually I remembered the new JavaScript project system. Those projects have an .esprojextension and their own SDK (first line in the project file):
<Project Sdk="Microsoft.VisualStudio.JavaScript.Sdk/0.5.127-alpha">
Interestingly, those kinds of projects are using launch.json from VS Code instead of launchSettings.json - which is horribly inconsistent.
But in this case, it was the key to get it finally working.
The task would be now, to get this working in a nice and integrated way which works without a secondary project and difficult setup.
This is just one part of what described above, but it's the most important one.
sw
oggy22
commented
10 months ago It's great that you made it working. I've created an internal item to track that so we will consider implementing this feature. It will be probably helpful that you made it working already.
softworkz
commented
10 months ago Great! Let me know when you need any more information!
Describe the feature/enhancement you need
With projects from the AspNetCore area, it is already possible to achieve a fully integrated and seamless development workflow, which is not even specific to WebView2 but also works with regular Chrome and Edge. It allows you to step through code across the borders: You step through while debugging and at one time you are in C# code and the next step brings you to a JavaScript file - all inside Visual Studio. This is driven or enabled by BrowserLink which connects both worlds together, maps files from the IDE to the browser environment restarts everything when needed and live-updates CSS styles when you make changes to these files in Visual Studio.
Getting this working for all projects with WebView2, rather than for ASP..Net only would be an amazing capability.
The scenario/use case where you would use this feature
When developing applications with WebView2, it is often required to debug both: your native application code and JavaScript code which is running inside the webview. For JS, you need to use Edge DevTools, then there's VS for debugging host code and then there's the view itself (in the application), which makes you end-up having three ((often large) windows/applications between which you need to switch back-and-forth all the time and of course, it's always the one you need most, that is covered by another window. Also, the debugging and editing experience is quite different between VS and Edge DevTools. It doesn't take long to get used to one or the other, but frequent switching is inconvenient.
Features like Edit-and-Continue and Hot-Reload are increasing productivity massively as it allows to avoid a significant part of the countless stop-edit-recompile-relaunch sequences through which one needs to go during development. When a large part of your implementations is on the JavaScript side, though, then you are off and don't benefit from those. I've often been in a situation where I needed to make changes on both sides where I could apply all of them at the C# side, but I still needed to restart due to JS changes.
At one time I had a perfect setup with BrowserLink and JS debugging in VS where I even had that "kind of" edit-and-continue that is sometimes working in Chrome: it doesn't exactly continue at the same place but it jumps back a few stackframes and continues from there - which is still great. (unfortunately it stopped working at some time)
Being able to work like that would make a fundamental difference for me.
How important is this request to you?
Impactful. My app's user experience would be significantly compromised without it.
Suggested implementation
What should make this Feature Request an attractive candidate is the high ratio between win and effort, which is because large parts of what's needed are already there. The hard work has been done already and all it takes is to adapt and extend and to re-connect some dots in different ways.
BrowserLink - which handles the interaction between host and browser - is getting injected into pages served by Asp.Net automatically and it does it's job in a rather silent way. It tries to do everything automatically (like correlating content in the browser to files on the server) and often fails when things aren't exactly set up like a default Asp.Net project. So that way wouldn't be suitable for something which is supposed to work on any kind of project with WebView2. Either it would need to be made configurable for the things it needs to know - or probably it would be even better to have it as an object in the application. This would also allow it to have some extension points for customizing the behavior in different setups and maybe provide some events for coordinating reload with the application.
Since there is no Asp.Net server it would need a different means for communication with the webview inner and injecting the initial code, but I think there are sufficient ways how it can be done.
For the JS debugger, it would be great when it could be improved in handling edit-and-continue (Hot Reload) and setting runtime variables in break mode.
But most import of all: That it just works..
AB#48455156