Remote machines cannot connect to Visual Studio web server

Question

Hi guys,

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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