The trip down the writing of a IE managed extension path continues… Dealing with the potholes (i.e. Debugging)

vcsjones - Writing a Managed Internet Explorer Extension: Part 4–Debugging

“Picking up where we left of with Writing a Managed Internet Explorer Extension, debugging is where I wanted to go next. I promise I’ll get to more “feature” level stuff, but when stuff goes wrong, and it will, you need to know how to use your toolset. .NET Developers typically write some code and press F5 to see it work. When an exception, the debugger, already attached, steps up to the plate and tells you everything that is wrong. When you write an Internet Explorer Extension it isn’t as simple as that. You need to attach the debugger to an existing process, and even then it won’t treat you like you’re use to. Notably, breakpoints aren’t going to launch the debugger until the debugger is already attached. So we have a few options, and some tricks up our sleeves, to get the debugger to aide us.

…

…”

I keep hoping that Microsoft will rework the IE extensibility model (think how cool a more simple model like that used by Visual Studio and MEF would be in IE?) but until then, now that with .Net 4 it’s “safe” to write managed extensions for IE, this is an interesting series to follow…

Also see;

• Writing a Managed Internet Explorer Extension: Part 3 (GD: Life as an IE BHO on Vista/Win7)
• Writing a Managed Internet Explorer Extension: Part 2.5 (GD: More event attaching)
• Writing a Managed Internet Explorer Extension: Part 2 (GD: Initial event attaching)
• Writing a Managed Internet Explorer Extension: Part 1 (GD: Intro, simple sample)

 

Related Past Post XRef:
Want to write Managed IE/Shell Extensions, but thought that was “bad”? That was the past… With .Net 4 the world of Managed Extensions is now open to you.
Taking your first steps with spicIE
Spice up your IE with spicIE – Writing IE7/8 Plugins in managed code in minutes (beta)