Icon

Goodbye AxWebBrowser

It wasn’t a perfect marriage, but we made it work. Your early death was documented here: IE7 Broke My AxWebBrowser!!!

I didn’t like how fat you were, between MSHTML and those two references I can never remember AxSHDocVw and SHDocVw. But you worked, and that’s all I ask.

To move over to the default WebBrowser component that comes with VS2005 I require the following things:

  1. Able to complete form items automatically.
  2. Able to click buttons on the page.
  3. Execute javascript functions on the page.
  4. Handles the new window and allows me to pop it into another web browser control.
  5. When doing #3, my ASP.NET session persists.

Ok, first we start with able to complete form items automatically.

WebBrowser1.Document.GetElementById(“txtUserName”).SetAttribute(“value”, “username”)
WebBrowser1.Document.GetElementById(“txtPassword”).SetAttribute(“value”, “password”)

CHECK!

Next, can we click a button?

WebBrowser1.Document.GetElementById(“btnLogin”).InvokeMember(“click”)

CHECK! So far much simpler than AxWebBrowser.

Now for the javascript function.

WebBrowser1.Document.InvokeScript(“myFunction”, New String() {“hello world”})

CHECK! Going great!

Here’s where we hit a snag. While WebBrowser has a NewWindow, it doesn’t give us any access to the URL. After some googling, I found someone who extended the component. Follow the directions posted by armoghan on 12/6/2007 found here.

So with that, you are given the event handler called NewWindowWithTarget, inside that event I place:

Dim frmWB As New Popup
frmWB.WebBrowser1.Navigate(e.Url)
frmWB.Show()
e.Cancel = True

And the session maintains!

And then my popups are handled! Except when I go to test it on some virtual machines, I find it does not work for Windows 2000. The author of the post did not indicate this, so I did some research. What he’s using is the NewWindow3 which was introduced with Windows XP SP2. If NewWindow3 fails, it moves on to NewWindow2 which pops up a separate IE process and loses the session. It works on IE6, IE7, or IE8 as long as you are Windows XP SP2 or higher. So that kills Windows 2000, and you can not even get IE7 for Windows 2k, so I’m screwed.

We had to make a tough call and we decided it was time to let go of Windows 2000 support. It’s been almost 9 years since it’s creation and 4 since Microsoft began to end the product life cycle. We’re able to lose the old AxWebBrowser and all the extra baggage. I hate to do it, but what choice do I have? Keep using IE6 for years?

Sigh. Check.

IE7 broke my AxWebbrowser!!!

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

ClickOnce Cert Expired Issue Solved By RenewCert of May.be

Yesterday, I went to publish a new version of our clickonce application, when I was greeted by a message that Visual Studio wasn’t going to let me publish, because our certification had expired. Oh no.

We’d often talked about getting a real certification and not using the temporary one, but we never saw the real benefit, and now in hindsight, I’m really glad we did not.

So, here’s the problem:

After your first clickonce publish, Visual Studio creates a certification key file, and stores it in your project as “ProjectName_TemporaryKey.pfx”. As far as I can tell, this is used only to sign the manifest it’s never sent to the client. The only visible downside is when installing the application, it warns that it’s an unknown publisher. This temporarykey, like actual keys are good for one year from the issue date.

Once that year is up, you can’t publish anymore. If you change certs, your updates no longer work (The deployment identity does not match the subscription. ) and everyone has to reinstall the application. It seems that Microsoft acknowledges that this was by design but it was bad design, and I believe it’s much better in VS 2008.

So panic sets in, we talk about abandoning clickonce, how to get these updates to people in the mean time. We found a knowledge base article, which offers two work arounds. http://support.microsoft.com/kb/925521

The first work around is out of the question, if we do that, we get rid of clickonce for good.

The second work around, sounds confusing and I feel like we get one shot, if that doesn’t work the project is gone.

Then, I find my new favorite website: http://www.may.be/renewcert/, A wonderful person, Cliff Stanford, seems to have encountered this problem, and took Microsoft’s Workaround #2 and made it better and offered some real help.

I downloaded his version of renewcert, and tried it on one of my temporarykeys. I used the following command at first: renewcert MyProject_TemporaryKey.pfx MyProject_FiveYearKey.pfx CN=”My Company” super_dooper_password

It failed.

I got the following error:

PFXImportCertStore failed with error 0×56: The specified network password is not correct.

I didn’t see any mention of this on Cliff’s site so I started to get worried again. Decided to try again, this time, I looked at how the temporarykey was issued.

renewcert MyProject_TemporaryKey.pfx MyProject_FiveYearKey.pfx CN=”MYDOMAIN\MYUSERNAME” super_dooper_password

I had no clue what to use as password, my current domain password? The one from a year ago? I did some googling and found that when VS creates these certs, it doesn’t use a password, so I left it off:

renewcert MyProject_TemporaryKey.pfx MyProject_FiveYearKey.pfx CN=”MYDOMAIN\MYUSERNAME”

It worked! I went into VS, went to the Signing Tab in the project properties, did “Select From File”, picked my new fiveyear cert. It added it to the project for me, and extened my expiration date to 2013!

IF we would have used a real certification, I think we would have been in trouble. You would need your certification agency to issue you a new cert every year, but it would have to use the same key. This isn’t something they do often.

So, we’re going to keep on keeping on, and migrate off of ClickOnce eventually, but atleast we were bought some time. I’m suprised this issue only cost me about an hour of my time, and a little worrying.

Thank you Cliff Stanford of may.be

Storing an image in dataset, proper type.

Just a quick one, if you want to store an image to a dataset, and are creating the dataset in code, here’s the proper type:

System.Type.GetType(“System.Byte[]“)

It’s a little confusing because if you use Visual Studio’s XSD editor, it lists the type as System.Byte(). And of course System.Byte would compile but it would not behave as expected.

In the schema, the type is stored as: type=”xs:base64Binary”

Just a heads up.

 

 

IE7 – Webbrowser Control breaks select tag functionality

Found a real frustrating one today:

My application is a blend between a web app and an actual windows form application. You can either access the web app or the windows form app. A few of the more complex features are only available to you if you run the windows form app.

To share features between the two, I just embedded a web browser control on a tab, and I have it bring up the web application.

Everything has always worked great, until I upgraded a test machine to IE7. Turns out all of my dropdown boxes (select tags) inside the application’s web browser control stopped working.

So, to recap, my dropdowns work in IE7, IE6, Firefox, but they don’t work inside my application which is using IE7’s Web Browser Control.

I found the offending piece of code that I had to remove. We were doing a little style to the select boxes when you clicked on them, apparently this version of IE7 did not like it.

Offending Code:

function colorChanger(obj)
{
if (obj.style.backgroundColor == '#f00')
{
return true;
}
else
{
if (obj.style.backgroundColor == '')
{
obj.style.backgroundColor = "#eeeeee";
}
else
{
obj.style.backgroundColor=(obj.style.backgroundColor=="#ffffff"?"#eeeeee":"#ffffff");
}
}
}

I used this code like this: