Today was a rough day.

The application I work on is a click once app, that contains a heavily integrated web browser. At first I went with Visual Studio’s default web browser control, but because of it’s short comings, I went back with the COM component, AxWebbrowser from the VB6 days.

Life was fairly well with AxWebbrowser, until I upgraded to IE7. While it still navigated, i lost nearly all of my event handlers, thus making it worthless. It took quite some time for me to even realize it was IE7 that broke it. I had upgraded weeks ago, and completely overlooked this huge flaw in the system the whole time, thinking it was something completely different.

So, being really under the gun, here’s what little I know. When upgrading to IE7, I lost NavigateComplete, DocumentComplete, and NewWindow2 events. I still had the Enter and ClientResize events. I tried removing the control, removing the automatic handler code, and even creating the handler manually, all to no avail. It never hit the breakpoint.

I was able to find an older copy of AxSHDocVw.dll and SHDocVw.dll in one of my previous projects. SHDocVw.dll was four kb’s smaller and had a different modification date. AxSHDocVw.dll was the same size but also had a different modification date. I tried copying over these new files, and referencing them to no avail.

There’s not much on google about this problem, some guy said enable scripts in IE7, which I thought was crazy but couldn’t find the setting he was talking about to completely debunk it. Some said IE7 developers did this by mistake but offered no help. Other than that, just a lot of confusion and Microsoft complaining. I wonder if Microsoft may be attempting to get a little more secure by cutting out this feature rich browser.

Likely for me, my supervisor had no upgraded yet, so we were able to load the project up and deploy it on his IE6 machine. I am happy to report that IE7 makes no changes to the project, it’s just not developer friendly from an IE7 machine. The client machines running on IE7 or IE6 only have problems when an IE7 machine published the project, the clients browser does not matter.

So, I’m not sure what I’m going to do in the next few days to try to ultimately resolve this. Here’s my thought process:

1. Try removing IE7 and see if everything is back to normal, a short term and unlikely fix.
2. Perhaps IE7 while killing AxWebbrowser, finally brought their default webbrowser up to snuff.
3. Take a serious look at either a Google Chrome component or a Mozilla component.
4. Pray.

Well, I made this blog to solve tough issues where google fails, me and it’s rare. But like the empty click once message, I was shocked how little information there was out there on this problem. So, I’m posting this as a place holder, if I solve this problem I promise to come back and let you know how I fixed it. If you don’t see an update, you can assume I failed.

UPDATE: Uninstalling IE7 did not fix this. My AxWebbrowser control still does not work. I might as well put IE7 back on.

UPDATE: Checked in to geckofx. Seems like too big of a reference and some complaints about slow start up time. Chrome’s chromiumembedded seems promising but it’s not even in beta yet. Back to the WebBrowser control.

UPDATE: I went with the Visual Studio default Browser, and was able to reproduce what I did in AxWebBrowser, how I did it here:  Goodbye AxWebBrowser