Jeff Sanders Technical Blog

I am a Microsoft employee that has worked on all aspects of the Web Stack for a long time. I hope these blogs are useful to you! Use this information at your own risk.


Earlier Posts

You have a .NET 2.0 control hosted in a browser.  The control uses the System.Uri class.  When upgrading to .NET 2.0 SP1 you can get an error: System.ArgumentException: Absolute path information is required.


CHttpServer and CHttpFilter are not included in Visual Studio 2008.  You will get error messages such as: fatal error RC1015: cannot open include file ‘afxisapi.rc’ fatal error C1083: Cannot open include file: ‘afxisapi.h’: No such file or directory.  You have to convert your projects to straight ISAPI API calls or come up with some other scheme (such as building the MFC libraries from another version of Visual Studio).  I used the following steps to build a CHttpServer based project in the Visual Studio 2008 environment as a temporary workaround so that you can build your projects based on CHttpServer:<p class=MsoNormal style="MARGIN: 0in 0in 0pt">How to build CHttpServer based projects with VS 2008.</p> <p class=MsoNormal style="MARGIN: 0in 0in 0pt">The MFC ISAPI classes have been removed from VS 2008.  I suggest you convert over to straight ISAPI calls since in reality these classes are simply a very thin wrapper around ISAPI API’s.  Also, you own the code that you move over and build this way and you will not be able to get any security updates of support if you use this method.</p> <p class=MsoNormal style="MARGIN: 0in 0in 0pt">I recently converted a couple of projects that had been built with the MFC wizard in VS 2003.  For these I found by statically linking with the MFC libraries and copying some files from my VS 2005 environment to a local directory in my project, the projects built under VS 2008.</p> <p class=MsoNormal style="MARGIN: 0in 0in 0pt">Statically Link with MFC libraries.</p> <p class=MsoListParagraph style="MARGIN: 0in 0in 10pt 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 level1 lfo1">



Prashant from my team found this interesting issue.  I will blog it here until the KB comes out on this.


I know… This is a simple thing, but there is no documentation on it so here it is:


By design the WebBrowser Control does not close the parent Form when WebBrowser Control is closed.  Here is one way you can accomplish this.


The articles referenced in my post Internet Explorer WebBrowser Control loses state… discusses sinking this event by adding an unmanaged version of the WebBrowser control to your Form and using that.  But what if you want to use the Managed version?  The manged version of the WebBrowser control is really a wrapper around the unmanaged version of the control and has some neat features like automatically docking to the form.


When you convert an MFC ISAPI project you created in an early version of Visual Studio to MFC 8 (VS 2005) you may notice that there is an extra set of carriage return linefeed characters.  This will be true if your code does not add a header to the return stream.  You can see this if you take the default project and comment out the lines as shown below:<p class=MsoNormal style="MARGIN: 0in 0in 0pt">


Session state for a web site is often stored in cookies.  If you use the WebBrowser control in an program and the target website responds to an action with a call to Window.Open, then mysteriously the cookies for that site are not transmitted with the request.


This was an interesting error that I had to hunt down.  When specifying a proxy server in .NET like this: WebProxy(“https://someproxyserver”) you will get this error.  You will get this error for whatever scheme that you enter before the “://” characters.  For example if you use this: WebProxy(“somescheme://someproxyserver”) Then you will get the error message: The ServicePointManager does not support proxies of somescheme scheme.  The only scheme that is recognized by this class is http.


So What?  You may ask.  This sometimes may be confusing to users!