Remote machines cannot connect to Visual Studio web server

Question

I remember when MS was developing Cassini - I believe they rolled it into VS 05/08, so I think this is a Cassini web server question.

I am using Windows XP with Visual Studio 2008, and find it quite inconvenient when I want to test a web page/styling with multiple browsers and multiple OSes. Right now I have to deploy the code on our server, and if there are any updates that need to happen, the process turns into quite a time drain. Since I am using XP/IIS 5, the option of using IIS is not an option. The use of IIS on XP requires an extra prefix for a project, which breaks all links, css etc. This was also a really quick development project so things like root dir that should be pulled out to config aren't, I am quite on board with this type of solution but it wasn't implemented in this project. It also seems really sketchy that MS wouldn't allow a simple flag somewhere to allow remote connections - its quite simple (http://www.devx.com/dotnet/Article/11711) but I don't want to recompile Cassini.

Does anyone know how to allow the integrated development web server in Visual Studio 2008 to be seen by other computers? This would save loads of time.

Flabellate

Answer 1

just figured out a good solution: 1) Set up fiddler on development machine 2) Set up remote machine to use fiddler as proxy 3) browse to http://localhost.:[insert your dev port # here]/ on remote machine

Chinchin

fiddler2.com/fiddler/help/reverseproxy.asp Step 2 is confirmed to work w/ VSDS. An example of my rule is: if (oSession.host.toLowerCase() == "192.168.1.138:8888") oSession.host = "localhost:35810"; – Tessera

The URL changed to fiddler2.com/documentation/Configure-Fiddler/Tasks/… – Tactless

Even better, a really small app without an installation (I have the GUI version which seems to be down, but the command line version works): quantumg.net/portforward.php It looks like you only need to run it once on the development machine: it just needs to forward to 127.0.0.1 and the HTTP host name doesn't matter. – Farinose

Answer 2

Sorry for answering an old question, but it ranks in Google so I decided to add my 2 cents:

In VS 2010 there's an option to use "IIS Express" instead of VS Development Server, which allows remote connections by default.

UPDATE: current version of IIS Express does not allow external connections by default, see HERE on how you can enable remote connections.

Fonteyn

Just installed IIS 7.5, but it doesn't accept external connections as default. So at least for me, this doesn't work. – Verecund

IIS Express does not allow external connections by default. In order to allow external access, see the answers here: #5434286 – Touchy

Answer 3

You can use a Port Forwarding Utility to listen in on a port, say 5000, and then relay all that traffic to Visual Studio's port.

The solution is described in the article, Accessing the Visual Studio ASP.NET Development Server from iPhone.

I have written a blog post based on the above article which summarizes it, Accessing Visual Studio Web Server remotely.

Jake

Answer 4

Microsoft doesn't allow this on purpose - they don't want you deploying your application with Cassini. It's compiled right into its code.

That being said, I've often wondered if they just check the url for "localhost". Perhaps editing the HOSTS file of the remote machine and redirecting "localhost" to the cassini machine could trick it? Worth a shot... In windows you can find HOSTS here:

C:\Windows\system32\drivers\etc

You can go into your web project settings and have it use the local IIS as a host instead, and then it will work fine.

Zanze

Hey Jedi - I forgot to mention I cannot use IIS since I am on 5 and that causes the root directory to be different, breaking all links and styling – Flabellate

I wasn't aware of any IIS 5.1 compatibility issues with VS - are you sure you can't troubleshoot that instead? – Zanze

Answer 5

To solve your problem of broken links, paths to files, etc. Use relative links.

Also, the token "~/" (without quotes) within URLs/path properties/values in ASP.NET's Server Controls will be automagically replaced with the real path to the IIS's subfolder where your application resides.

For this solution to work the root of the Web application you are developing must be an IIS Application (see your web project's properties pages at the Web section where you can find a link or button to create the IIS Application).

Google for IIS Web Application Root.

Grube

Answer 6

I test against multiple browsers on my local box. The local web server doesn't care whether you use Opera/Safari/Firefox/IE to connect to it. Typically I fire up the project in the debugger, which also starts IE, then cut/paste the URL from IE into whatever browser I'm testing with. Typically, the port Cassini chooses doesn't change often, so a lot of times the URL is already there in my browser history. Once the web server is running, you can even stop the debugger and continue to test in the alternate browser.

For other MacOS, I typically publish to a QA server with IIS6. I've found very few cases where after testing with IE/Firefox/etc. on WinXP, there were problems on the Mac. I don't specifically test variants of Linux.

Villiers

He's talking about loading IE in a VM like Virtual PC within one development box, and then connecting to the localhost on the host box (your actual computer) from the browser inside the VM. Much more convenient when debugging because you stay inside your IDE for debug and you don't have to deploy over and over. – Meliamelic

@Chris - My solution is to try and test with multiple browsers on my dev box to test various engines. I've had good success with this without having to resort to VMs. Once basically set, I deploy to QA (I do it anyway) and let other people with different browser/OS combinations hammer away at it. I'm probably spoiled in that I don't often have to worry about older browsers since my apps are generally internal and we do a pretty good job of upgrading browsers. Having to test multiple browser versions can be tricky and I could see where having VMs set up with different versions could be useful. – Villiers

Yeah, this post is not for you. You can't legitimately test multi versions of IE locally without VMs, so the key is making VM connections convenient. There are ways of side-by-side installing clones but the engines aren't quite the same, hiding bugs your users will see. – Meliamelic

Answer 7

Try binding .Net to 127.0.0.1 instead of localhost, it actually does make a difference with the resolution in some cases I encountered. I wish I had known that all along, would have saved me a number of hours.

I've also seen Privoxy used, which may be faster, but Fiddler is far easier and doesn't require setting up a loopback.

Anyways, I have VS setup on localhost:15709 and this in Fiddler: if (oSession.host.toLowerCase() == "webserver:15709") oSession.host = "localhost:15709";

So I just type webserver:15709 in my VM an it works great.

Topeka

Answer 8

Using Fiddler as reverse proxy, development web server could get the request, but it becomes internal request (127.0.0.1), which is useless in my case.

I'm trying to catch remote request to debug it on there.

Polyethylene

Why do those specifics matter? That sounds like something you could handle per-environment instead of looking at IP. – Meliamelic

Answer 9

WebMatrix is another alternative.

Pulmonic