Debugging an embedded Web Browser control in a Windows application can be a pain. The Web Browser control is essentially an embedded instance of the Internet Explorer engine, but it lacks any of the support tooling for debugging.
Visual Studio Studio HTML Debugging
But if you need to debug more complex code, using Console based output can only get you so far. A few days ago I had introduced a regression bug into the spell checking code in Markdown Monster and man was it tricky to debug. Console debugging had me running in circles.
Right around the same time I got a comment on the Firebug Debugging post that casually mentioned that you can use Script debugging in an EXE application by externally attaching a debugger to the EXE and then choosing Script Debugger. A bit of experimenting ensued...
I vaguely knew that Visual Studio can debug Internet Explorer code, but didn't put the pieces together to see how to do this with my own applications like Markdown Monster that are running an embedded Web Browser control. It didn't occur to me because standalone Windows projects like a WPF app don't offer script debugging as part of the debugging UI.
However it is possible to use Visual Studio for debugging the Web Browser control code, but you need to explicitly attach the debugger to do it. And since you are attaching to a process, it works with any kind of EXE application not just .NET applications.
To set this up:
- Start up your application from Explorer or Command Line
- In Visual Studio use Tools->Attach to Process
- Attach the Debugger to Script Code
- Pick your EXE from the Process list
Here's what the Attach Dialog should look like:
Once the debugger is attached, Visual Studio automatically tracks any scripts that are running in a Script Documents section in the Solution Explorer and you can open the document from there.
Markdown Monster uses HTML for the Markdown editor and also the preview so both of these pages and their scripts show up in the Script Documents section immediately.
Now to debug code:
- Open the script file from Script Documents (not from your project!)
- Set a breakpoint anywhere
- Run your code to the breakpoint
- Examine variables by hovering
- Fix broken sheiit
- Go on with your bad self!
- Type DOM Explorer into Quick Launch
Here's what all of this (minus the DOM Explorer) looks like in Visual Studio:
Once you have a breakpoint set you can examine variables and drill into objects just like you'd expect to do in Visual Studio.
Watch where you make Code Changes!
If you look at my screen shot you can see that the script file debugged is open and I can edit this file and make changes - if I reload the page (or open a new document in Markdown Monster for example) the change shows up in the executing code.
But be aware that the path to the script file will be in the application's deployment folder, not the file that might live in your project.
When you debug with the Visual Studio debugger, the files in Script Documents are the actual files running, which are in the deployment folder (ie.
\bin\Release). So if you make changes to a script file, make sure you copy those changes back to your project folders after you're done debugging or else the changes are simply overwritten the next time you compile your project.
You've been warned! 😃
I say this because I've done this more than a few times in the past - debugged my files made some changes, then recompiled the .NET project and: Faaaark!, I just overwrote my changes. Don't let that happen to you.
After I hooked up the debugger in Visual Studio I found my Spellcheck issue in Markdown Monster in a matter of a couple of minutes after previously spending well over an hour with trying to find the right
console.log() calls to try and trace down the bug.
Using the Attach to Process is a little cumbersome, and it makes it difficult to debug startup code debugging, but if you really need to debug a complex issue, this little bit of extra work is well worth the effort.
For .NET projects designed for Visual Studio, it would be nice though, if standard EXE debugging would have an additional option to start Script Debugging along side the .NET (or native) debugger, but I can live with Attach Debugger.
Other Posts you might also like