views:

1668

answers:

5
  1. Developing an ASP.Net website.
  2. Running IE8.
  3. Need to test website under IE6.
  4. MultipleIE6 install broken by IE8 install (can't type in textboxes, yes I deleted cache, yes I re-registered the dll's).
  5. Created VPC running IE6.
  6. Can't connect to host WebDev.WebServer.exe.

Is there any way to configure WebDev.WebServer.exe so that it will accept remote connections?

+4  A: 

AFAIK, WebDev is coded to specifically reject all external connections... so the short answer would be "no".

Best thing to do would be simply publish the website to your VPC running IIS and test it that way.

womp
It's quite a bit more friction to deal with publishing IIS or even just configuring local IIS to serve every project. You don't get to enjoy the Netbeans-like integrated web server and configuring non-admin debugging is a further complexification. You can instead take a small hit on configuring a personal proxy up front and forget about why it works after that.
Brian Reiter
@Brian - great idea, +1
womp
A: 

Hmm i am not shure this works, but try adding the WebDev.WebServer.exe to be unblocked from your Windows Firewall.

If this doesn't work you have to install IIS and set a virtual directory directly on your development folder.

Alexander
A: 

I use one of Microsoft's VPC images to test IE6 using the debug webserver, so I don't know what could be causing your issues. Sounds like it could be a networking issue with the virtual machine.

Also IEtester works well for quick checks of rendering and functionality. I have yet to see any major differences between the behavior in IEtester and the real IE6 under XP, but the possibility exists so I still check with the virtual machine before release to production.

http://www.my-debugbar.com/wiki/IETester/HomePage

Ariel
+6  A: 

The workaround for the way that webdev.webserver is crippled to refuse remote requests is to use a lightweight proxy server running on the same host as webdev.webserver. The remote browser then uses the proxy and its requests appear to webdev.webserver like requests originating from localhost. I've used Privoxy succesfully.

Sample config:

  • Configure Privoxy to listen on an IP address that is routable from your VM (eg 192.168.1.1:8118). You can put an IP address on a looback on your host OS and use NAT with the client OS.
  • Configure your browser(s) in the VM to use 192.168.1.1:8118 for its proxy for all connections including localhost.
  • Start your app in webdev.webserver
  • With your VM browser go to the same URL as you would with a browser on your host OS (eg http://localhost:3254)

From the perspective of webdev.webserver the requests will originate from Privoxy on 127.0.0.1 and it will happily serve them up.

Brian Reiter
It's important to note that other computers can do request to your WebDev.WebServer if you open the port (8118) in your firewall for Privoxy (for TCP requests).Also, the only configuration needed for Privoxy is to find the `listen-address` config in the Main Configuration and set it to the appropriate value (`listen-address 192.168.1.1:8118`).It works really well and isn't too hard to set-up.
GoodEnough
FWIW. I posted step-by-step instructions for setting this up here: http://thoughtfulcode.wordpress.com/2009/11/13/multiple-versions-of-ie-with-the-visual-studio-built-in-web-server-the-solution/
Brian Reiter
+1  A: 

I ran into this same issue, and after some research, found that the method detailed at this site worked for me: http://www.funkymule.com/post/2009/04/17/Making-ASPNET-Development-Server-Listen-for-Remote-Connections.aspx

It involves modifying and reassembling the Webdev server and DLL, but once it's all up and running, I've been able to use older versions of Internet Explorer running in VPC/XP Mode to connect to the WebDev server running on the host machine via the internal network IP (192.168.x.x).

Rudism
In the comments thread in that article, a user explains how to do a simple port forward. This seems more maintainable than hacking the DLL...http://www.funkymule.com/post/2009/04/17/Making-ASPNET-Development-Server-Listen-for-Remote-Connections.aspx#id_11ce7839-8d26-40b4-995b-8d592987dd73
Wayne Hartman