¿Cómo se compara el despliegue de aplicaciones .NET con la implementación de aplicaciones web Java?

Question

Es posible que tenga que admitir la implementación de .NET en un futuro próximo. Necesito poder hablar con las personas que están desarrollando esta aplicación y ser capaces de evaluar si tienen algún sentido de las mejores prácticas para el despliegue, o si, como sospecho, sus procesos son complicados y simplemente están confundiéndose.

Esto es un problema para mí porque soy desarrollador de Java y no hablo .NET. Entonces no entiendo cuáles deberían ser las mejores prácticas.

Entonces, para ponerlo en una perspectiva con la que me pueda relacionar, me gustaría saber qué es lo mismo y qué tiene de diferente la implementación de aplicaciones Java y Java EE frente a la implementación de aplicaciones .NET.

Cuando implemento una aplicación Java bastante básica en la web, generalmente tengo un proceso automático que obtiene el código del control de origen, ejecuta una secuencia de comandos ANT o Maven para generar un archivo .war, coloca ese archivo en un directorio webapps, y luego Tomcat - o algún otro servidor de aplicaciones - infla el archivo .war y lo hace funcionar.

¿Cuál sería el proceso equivalente en .NET? ¿Qué herramientas se usan comúnmente? ¿Qué artefacto se crea con un propósito similar al de un archivo .war? ¿Cuáles son las malas prácticas que son comunes, pero deben evitarse?

Answer 1

Assemblies en .Net son las más altas "paquete" de nivel se conoce. Son aproximadamente equivalentes a .jar files en Java. Hay sistemas en la parte superior de los ensamblados (como los paquetes Web Deploy), pero los utilizan las herramientas y los complementos de nivel superior; no son conceptos básicos de .Net.

En lugar de Ant, tenemos MsBuild.

Las soluciones de Visual Studio son combinaciones de proyectos de Visual Studio, y los proyectos de Visual Studio son scripts de MsBuild. Puede construir cualquiera de ellos con Visual Studio o MsBuild.

Los ensambles están compilados por the compiler. Utiliza una secuencia de comandos MsBuild para especificar qué archivos se compilan en el ensamblado y para especificar a qué otros ensambles se hace referencia.

. Los ensamblajes .Net pueden ver ensamblajes en el GAC (Global Assembly Cache - esto es todo el sistema) y montajes en el mismo directorio. No hay directorios de bibliotecas mágicas que se carguen como los hay del a Java WAR.

En el lado .Net, IIS es tanto el servidor web como el servidor de aplicaciones.

Tiene una cosa llamada application pools que se ejecuta bajo un usuario específico, y carga una versión específica de .Net Framework. Puede aplicarlos a nivel de "sitio" o nivel de "aplicación".

En IIS, tiene "sitios" (a veces simplemente "Sitio web predeterminado") y crea un "directorio virtual" en ese sitio. Entonces puedes "marcarlo como una aplicación". Vincula los directorios virtuales a los directorios del sistema de archivos reales y simplemente puede soltar los archivos que está implementando en ese directorio.

Ver: Understanding Sites, Applications, and Virtual Directories on IIS

No hay directorio de despliegue en IIS como hay servidores de aplicaciones Java. Deja caer sus páginas y ensambles directamente en el directorio desde el que se sirve.

Pero hay una estructura de directorios para sitios web. Los proyectos que ha creado en Visual Studio ya están configurados para que coincidan con esa jerarquía, por lo que puede simplemente tomar toda la carpeta del proyecto y lanzarla en IIS.

Si quieres hacer algo un poco más automatizado, mira en Web Deploy.

Answer 2

One word IIS. En cuanto a las aplicaciones que he desarrollado, ya sea el servicio o el sitio web, las despliego a través de IIS.

En la misma analogía que dijiste. Visual Studio genera la compilación de su aplicación web/sitio web que puede implementar en el servidor web a través de IIS y es totalmente configurable.

Todos los pasos y los precursores se pueden encontrar here