IIS Express en una máquina de desarrollo compartido (rdp)

Question

Tengo un problema que pensé que podría ser común, busqué en la web pero no encontré nada.

Estamos utilizando una máquina de desarrollo compartido, y todos los desarrolladores se conecta a través de RDP y tiene su propio perfil, escritorio, etc.

El problema que estoy encontrando es con IIS Express. Dado que está configurado a nivel de usuario (applicationhost.config dentro de documentos/iisexpress/config) y el puerto configurado debe coincidir con el declarado en el archivo .csproj, dos desarrolladores no pueden ejecutarse en el mismo puerto, ya que da el error "el puerto ya está en uso".

Para que funcione, tenemos que cambiar manualmente el puerto tanto en csproj como en applicationhost.config para cada desarrollador, pero es solo una solución temporal ya que cuando confirmamos nuestros cambios a SVN, el archivo csproj se fusiona , entonces tenemos que hacer este proceso cada vez que alguien se comprometa/actualice.

Mi pregunta es: ¿hay una forma clara de usar IIS express con Visual Studio 2010 en una máquina de desarrollo compartido?

Gracias.

Answer 1

Parcialmente probado la respuesta. No estoy seguro de cómo funcionará en una estación de trabajo multiusuario. Podría brindarle a usted, oa alguien más aquí, un impulso a una solución adecuada que funcione mejor en su entorno actual.

Parece que Visual Studio almacena toda la configuración web en csproj/vbproj e IISExpress almacena su configuración en% userprofile% \ Documents \ IISExpress \ config \ ApplicationHost.Config.

Normalmente, almacenamos los archivos csproj en control de fuente, pero ignoramos el archivo csproj.user para que cada persona tenga algunas configuraciones únicas, como la configuración web.

• Cada usuario que inicia sesión en el cuadro debe tener su propio perfil.
• Cada perfil debe tener su propia copia del código fuente.
  • Cada copia de la fuente del usuario contendrá su propio archivo csproj.user.
• Ignorar. ** archivos proj.user * en el control de origen.

Copiar la configuración web en el csproj.user desmarcando la opción de configuración del servidor Aplicar a todos los usuarios y luego comprometerse a control de código fuente.

Cada usuario que saca una copia de la fuente tendrá que ajustar su configuración web, utilice un puerto único que los demás usuarios no están utilizando, y desactive el cuadro de arriba para que su configuración no se transmite a la otros usuarios.

Al hacer esto, cada perfil tendrá su propia IIS Express ApplicationHost.Config configurada con un puerto que es diferente de los otros perfiles. Cada copia de la fuente del usuario tendrá un csproj.user configurado con el mismo puerto en la configuración de IIS Express de su perfil.

Como referencia:

He intentado cambiar ApplicationHost.config de IIS Express para utilizar un puerto diferente a lo que espera de Visual Studio y Visual Studio no se puede conectar al depurador que IIS Express.

¿Cómo funciona la configuración de IIS Express: http://msdn.microsoft.com/en-us/library/ms178109.aspx

Answer 2

La mejor opción que puede utilizar es aprovechar el Import functionality integrado en MSBuild.

Esencialmente, crearía un objetivo de compilación separado para cada usuario. A continuación, puede importar este objetivo desde este archivo al que se hace referencia directamente. Entonces recomendaría crear este archivo en el servidor (para cada usuario), pero dejándolo fuera del control de la fuente.

Esto debería permitir a cada usuario tener un puerto IIS personalizado sin entrar en conflicto con otros.

Answer 3

Creo que puede crear subdominios para cada usuario e implementar los cambios necesarios y hacer las pruebas. De esta forma, cada usuario puede tener su propio subdominio y puerto y, por lo tanto, trabajar independientemente en el IIS Express compartido.

Answer 4

Es probable que no va a gustar mi respuesta, pero aquí están mis pensamientos:

Como habrá notado, las configuraciones están vinculados al perfil del usuario y no del servidor; esto se debe a que IIS Express no está destinado a ser utilizado como un servidor de desarrollo compartido. Debería usar IIS completo.

No veo ningún beneficio o razón para usar la misma caja física para el desarrollo. Es cierto que no conozco todos los detalles de su escenario con licencias o recursos de estaciones de trabajo, pero no parece que gane mucho con tener a todos los RDP en la caja para usar Visual Studio: cada persona aún necesita una licencia, el rendimiento ser más lento, y no debería estar trabajando en la misma instancia del proyecto.

Usted debería considerar seriamente toda su configuración para el desarrollo:

Cada desarrollador debe utilizar Visual Studio en su puesto de trabajo, y la depuración/prueba no utiliza IIS Express (configurado con los mismos puertos y la configuración a través de todas las máquinas - muy fácil)

A partir de ahí, los desarrolladores deben verificar su código en el control de código fuente y examinar los conflictos que pueden surgir o no. No estoy seguro acerca de SVN, pero la automatización de MSBuild disponible en TFS se puede usar para configurar una política de compilación continua que se implementa en una instalación IIS común para que su código fusionado se pruebe y pueda usar desde la instalación completa de IIS mencionada anteriormente.

Cualquier otra cosa sería una solución/truco que te morderá en el trasero más tarde.