how to debug Blazor WebAssembly application by renaming the browser

Our team needed to debug Blazor WebAssembly applications in Yandex Browser. But a problem arose: Visual Studio stubbornly refused to hit breakpoints. There were no such problems with either Edge or Chrome, although all three browsers are based on Chromium. I tried to figure out how and what was happening there, although I didn’t really believe in success.

I decided to focus on two points. Mandatory presence in the file launchSettings.json parameter inspectUrias well as for the obligatory method call UseWebAssemblyDebugging. First, I looked into the source code of the method and noticed that the address was mapped in it “/_framework/debug”. If there is an address, then someone must contact it. I copied part of the code of this method to see how it is called and with what parameters. Two things I noticed. Firstly, the method is called immediately before the page is loaded, which means it is most likely called by Visual Studio itself, and not by the application. And secondly, the method was not called for Yandex.Browser. A parameter for integration with DevTools was passed to the method itself.

There were attempts to try to call this method yourself, but this did not lead to any success in my case. It was useful to google the mention of the parameter in the .NET repositories inspectUribut this also did not lead to success. This option was mentioned only in the VS Code repositories, which finally convinced me that the debugging process is completely built into the closed sources of Visual Studio. And then I thought: how then does Visual Studio determine which browser can be debugged in and which cannot? As we have determined, it definitely does not look at the browser engine. Either somehow, through a conditional UserAgent, it determines the browser itself (and the names are protected for only two browsers), or… it looks at the name of the exe file. Moreover, in Visual Studio it is possible to add an arbitrary browser and somehow it must determine its type. The idea, of course, seemed absurd to me, but I decided to try.

Create a copy of browser.exe and rename it chrome.exe.

Adding a “new” browser

We try to debug and see that everything suddenly worked out for us!

I think you can draw your own conclusions from everything written.

PS Later they gave me a link to a similar article (The title matters: how to get optimization by renaming the browser), so I made the title in a similar style 🙂

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

how to debug Blazor WebAssembly application by renaming the browser

Our team needed to debug Blazor WebAssembly applications in Yandex Browser. But a problem arose: Visual Studio stubbornly refused to hit breakpoints. There were no such problems with either Edge or Chrome, although all three browsers are based on Chromium. I tried to figure out how and what was happening there, although I didn’t really believe in success.

I decided to focus on two points. Mandatory presence in the file launchSettings.json parameter inspectUrias well as for the obligatory method call UseWebAssemblyDebugging. First, I looked into the source code of the method and noticed that the address was mapped in it “/_framework/debug”. If there is an address, then someone must contact it. I copied part of the code of this method to see how it is called and with what parameters. Two things I noticed. Firstly, the method is called immediately before the page is loaded, which means it is most likely called by Visual Studio itself, and not by the application. And secondly, the method was not called for Yandex.Browser. A parameter for integration with DevTools was passed to the method itself.

There were attempts to try to call this method on our own, but this did not lead to any success in my case. It was useful to google the mention of the parameter in the .NET repositories inspectUribut this also did not lead to success. This option was mentioned only in the VS Code repositories, which finally convinced me that the debugging process is completely built into the closed sources of Visual Studio. And then I thought: how then does Visual Studio determine which browser can be debugged in and which cannot? As we have determined, it definitely does not look at the browser engine. Either somehow, through a conditional UserAgent, it determines the browser itself (and the names are protected for only two browsers), or… it looks at the name of the exe file. Moreover, in Visual Studio it is possible to add an arbitrary browser and somehow it must determine its type. The idea, of course, seemed absurd to me, but I decided to try.

Create a copy of browser.exe and rename it chrome.exe.

Adding a “new” browser

We try to debug and see that everything suddenly worked out for us!

I think you can draw your own conclusions from everything written.

PS Later they gave me a link to a similar article (The title matters: how to get optimization by renaming the browser), so I made the title in a similar style 🙂

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *