When you are trying to use Quick Watch or evaluate some DotNetBrowser expressions when your application is paused by debugger (e.g. a breakpoint was hit), you can notice the following behavior:
- Visual Studio hangs and seems to be waiting for something. For example, setting a breakpoint after obtaining a DOM element and then inspecting its properties results in VS hanging for minutes and then nothing really useful coming back.
- In the Quick Watch you can see "The function evaluation requires all threads to run." message for many properties of the DotNetBrowser-related objects.
The Chromium engine runs in a separate process. DotNetBrowser library uses multiple threads for exchanging data between the Chromium engine and the .NET side. Almost any evaluation involves IPC, because DotNetBrowser does not perform any data caching itself.
When Visual Studio stops the application at some breakpoint, some of DotNetBrowser threads are getting paused. In this case our library cannot obtain data and process requests from Chromium process. This is why you cannot evaluate expressions in the debugger.
This issue is rather common when debugging multi-process applications, not only DotNetBrowser. As a workaround you can use logging to display required data at runtime.