Las máquinas remotas no se pueden conectar al servidor web de Visual Studio

Recuerdo que cuando MS estaba desarrollando Cassini, creo que lo incluyeron en VS 05/08, así que creo que esta es una pregunta del servidor web de Cassini.

Estoy usando Windows XP con Visual Studio 2008, y me resulta bastante incómodo cuando quiero probar una página web / estilo con múltiples navegadores y múltiples sistemas operativos. Ahora mismo tengo que implementar el código en nuestro servidor, y si hay alguna actualización que deba suceder, el proceso se convierte en una pérdida de tiempo. Como utilizo XP / IIS 5, la opción de usar IIS no es una opción. El uso de IIS en XP requiere un prefijo adicional para un proyecto, lo que rompe todos los enlaces, css, etc. Este también fue un proyecto de desarrollo muy rápido, por lo que cosas como el directorio raíz que debería extraerse para configurar no, estoy bastante bordo con este tipo de solución, pero no se implementó en este proyecto. También parece realmente incompleto que MS no permita una simple bandera en algún lugar para permitir conexiones remotas, es bastante simple ( http://www.devx.com/dotnet/Article/11711 ) pero no quiero recomstackr Cassini.

¿Alguien sabe cómo permitir que otras computadoras vean el servidor web de desarrollo integrado en Visual Studio 2008? Esto ahorraría mucho tiempo.

acabo de descubrir una buena solución: 1) Configurar el violinista en la máquina de desarrollo 2) Configurar la máquina remota para usar el violinista como proxy 3) navegar a http://localhost.:[insert your dev port # here ] / en la máquina remota

Perdón por responder una pregunta anterior, pero figura en Google, así que decidí agregar mis 2 centavos:

En VS 2010 hay una opción para usar “IIS Express” en lugar de VS Development Server, que permite conexiones remotas por defecto.

ACTUALIZACIÓN: la versión actual de IIS Express no permite conexiones externas de forma predeterminada; consulte AQUÍ sobre cómo puede habilitar conexiones remotas.

Puede usar una utilidad de reenvío de puerto para escuchar en un puerto, digamos 5000, y luego retransmitir todo ese tráfico al puerto de Visual Studio.

La solución se describe en el artículo Acceso al servidor de desarrollo ASP.NET de Visual Studio desde iPhone .

He escrito una publicación de blog basada en el artículo anterior que lo resume, Accediendo a Visual Studio Web Server de forma remota .

enter image description here

Microsoft no permite esto a propósito; no quieren que implemente su aplicación con Cassini. Está comstackdo directamente en su código .

Dicho esto, a menudo me pregunto si solo verifican la url de “localhost”. Tal vez la edición del archivo HOSTS de la máquina remota y la redirección de “localhost” a la máquina Cassini podría engañarlo. Vale la pena intentarlo … En Windows puedes encontrar HOSTS aquí:

 C:\Windows\system32\drivers\etc 

Puede acceder a la configuración de su proyecto web y hacer que use el IIS local como host, y luego funcionará correctamente.

Para resolver su problema de enlaces rotos, rutas a archivos, etc. Utilice enlaces relativos.

Además, el token “~ /” (sin comillas) dentro de las URL / propiedades / valores de ruta en los controles de servidor de ASP.NET se reemplazará automágicamente con la ruta real a la subcarpeta de IIS donde reside su aplicación.

Para que esta solución funcione, la raíz de la aplicación web que está desarrollando debe ser una aplicación IIS (consulte las páginas de propiedades de su proyecto web en la sección web donde puede encontrar un enlace o botón para crear la aplicación IIS).

Google for IIS Web Application Root.

Pruebo contra múltiples navegadores en mi casilla local. Al servidor web local no le importa si usa Opera / Safari / Firefox / IE para conectarse. Normalmente, inicio el proyecto en el depurador, que también inicia IE, y luego corté / pegué la URL de IE en el navegador con el que estoy probando. Normalmente, el puerto que Cassini elige no cambia a menudo, por lo que muchas veces la URL ya está allí en el historial de mi navegador. Una vez que el servidor web se está ejecutando, incluso puede detener el depurador y continuar con la prueba en el navegador alternativo.

Para otros MacOS, normalmente publico en un servidor de QA con IIS6. He encontrado muy pocos casos donde después de probar con IE / Firefox / etc. en WinXP, hubo problemas en la Mac. No pruebo específicamente variantes de Linux.

Intenta vincular .Net a 127.0.0.1 en lugar de localhost, realmente hace una diferencia con la resolución en algunos casos que encontré. Ojalá lo hubiera sabido todo el tiempo, me habría ahorrado un número de horas.

También he visto utilizar Privoxy, que puede ser más rápido, pero Fiddler es mucho más fácil y no requiere configurar un bucle.

De todos modos, tengo configuración VS en localhost: 15709 y esto en Fiddler: if (oSession.host.toLowerCase () == “webserver: 15709”) oSession.host = “localhost: 15709”;

Así que simplemente escribo webserver: 15709 en mi VM y funciona muy bien.

Usando Fiddler como proxy inverso, el servidor web de desarrollo podría obtener la solicitud, pero se convierte en una solicitud interna (127.0.0.1), lo cual es inútil en mi caso.

Estoy intentando capturar la solicitud remota para depurarlo allí.

WebMatrix es otra alternativa.