Diferencias entre compilar un sitio web y una aplicación web

Hay muchas variedades de módulos ASP.NET basados ​​en varias plataformas, como formularios web, páginas web, modelo-vista-controlador (MVC) y el más reciente: Core. En este artículo, quiero ver una serie de diferencias entre compilar un sitio web ASP.NET y una aplicación web ASP.NET.



Compilación de un sitio web (Fig. 1) y una aplicación web (Fig. 2).



Fig. 1: sitio web ASP.NET y la distinción entre el sitio web ASP.NET y la aplicación web ASP.NET



Fig. 2: aplicación web ASP.NET y la distinción entre el sitio web ASP.NET y la aplicación web ASP.NET

Este artículo no trata sobre la estructura interna de los proyectos ASP.NET, sino sobre la experiencia que obtuve mientras trabajaba en la plataforma Azure App Service. El dispositivo interno ya está documentado aquí : “Precompilación de su sitio web (C #)” (“Precompilación de un sitio web en C #”). Debe comprender la diferencia entre compilación automática y explícita. Además, si está tratando con un sitio web ASP.NET, considere seriamente precompilar con aspnet_compiler.exe, como se describe en Cómo precompilar sitios web ASP.NET (Cómo precompilar sitios web ASP.NET ").

Aquí hay una serie de publicaciones que lo ayudarán a ampliar sus horizontes sobre este tema y explorar otros temas:


Entonces, ¿dónde empezó todo? Quería verificar si entendía el proceso de compilación de módulos ASP.NET en ensamblajes correctamente, y decidí hacerlo en el entorno del Servicio de aplicaciones de Azure. Ya tenía un concepto sobre los archivos ASP.NET temporales, sobre la compilación de archivos ASPX en un ensamblado .dll y sobre dónde se almacenaban en un servidor independiente. Estaba seguro de que en la plataforma App Service los primeros dos puntos se implementaron de manera similar, pero dudé del tercero, es decir, dónde se almacenan los ensamblajes compilados. Entonces escribí un código para averiguarlo.

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater> 

Luego publiqué este código en la plataforma App Service.

Cuando accedí por primera vez al sitio web, obtuve el resultado que se muestra en la Fig. 3 (originalmente en la raíz de mi sitio web ASP.NET tenía tres páginas)



Fig. 3: compilar un sitio web ASP.NET en la plataforma Azure App Service

Reinicié el sitio web y los binarios se compilaron en un nuevo ensamblaje (Figura 4). Esto fue bastante inesperado, ya que solo reinicié y no hice ninguna implementación o cambio.



Fig. 4: compilar un sitio web ASP.NET en la plataforma Azure App Service

Busqué en KUDU el directorio de ensamblado y no lo encontré; Fue muy extraño.

Después de hacer clic en los enlaces "Otra página" y "Y otra página", todas mis páginas se compilaron en un ensamblaje, y me sorprendió mucho encontrar esto, ya que debug = true se configuró en mi archivo web.config.

Necesitaba encontrar las respuestas a las siguientes preguntas:

  1. ¿Por qué mi aplicación se compiló después del reinicio, aunque no realicé ningún cambio de implementación o configuración?
  2. ¿Por qué no encontré el ensamblado en KUDU a pesar de que mi código fuente era correcto?
  3. ¿Por qué mi aplicación se compiló en un solo ensamblaje, aunque debug = true se configuró en el archivo web.config?

La respuesta a la primera pregunta fue que en realidad estaba mirando el ensamblado de KUDU, no el que se compiló para el Servicio de aplicaciones. Eche un vistazo a la Figura 2 en el artículo "Crear un volcado de memoria para su aplicación web de bajo rendimiento". Esto muestra que KUDU se está ejecutando en un proceso diferente al del Servicio de aplicaciones. Por lo tanto, KUDU se recompiló al crear la instancia, y no fue mi instancia del Servicio de aplicaciones.

También resolví la segunda pregunta según la información recibida sobre la primera pregunta. Omitiré detalles sobre la configuración de los archivos en la plataforma de App Service y diré que pude mostrar los ensamblados de mi sitio web ASP.NET en esta plataforma: para esto configuré WEBSITE_DISABLE_SCM_SEPARATION en verdadero (ver Figura 5). Haga esto solo para probar y (o) depurar y para nada más. No recomiendo asignar varias páginas de un sitio web a un solo proceso en App Service. Una vez completada la depuración, restablezca este valor y vuelva a separar los procesos.



Fig. 5: compilar el sitio web ASP.NET en el Servicio de aplicaciones de Azure; No puedo encontrar archivos temporales ASP.NET en KUDU

La respuesta a la tercera pregunta fue que si el archivo Web.Debug.config está presente, el atributo debug = true se elimina durante el proceso de implementación.

 <compilation xdt:Transform="RemoveAttributes(debug)" /> 

Escribí sobre archivos XDT aquí , aquí y aquí , pero en este caso tuve que pensar un poco para entender (recordar, comprender) su significado.

Después de establecer el parámetro WEBSITE_DISABLE_SCM_SEPARATION en verdadero, paré y comencé, en otras palabras, un arranque en frío ... y vi que, de hecho, tanto SCM / KUDU como mi sitio web comenzaron en el mismo proceso (Fig. 6.)



Fig. 6: compilar el sitio web ASP.NET en el Servicio de aplicaciones de Azure; No puedo encontrar archivos temporales ASP.NET en KUDU

Se inicia la publicación y compilación de default.aspx, el nombre del ensamblado permanece sin cambios después de todas las solicitudes (Fig. 7).



Fig. 7: compilar un sitio web ASP.NET en la plataforma Azure App Service

Para verificar esto, realicé un volcado de la memoria del proceso, realicé un volcado del módulo y lo analicé. Honestamente, todavía estaba desconcertado por el resultado mostrado por el ensamblado, porque descubrí el parámetro debug = true solo después de que se completaron todas las pruebas. A veces escribo artículos en el orden incorrecto en el que siguen los eventos. Confundido, decidí probar la compilación por lotes; lea sobre esto aquí : "Elemento de compilación (esquema de configuración de ASP.NET)" ("Elemento de compilación - Esquema de parámetro web de ASP.NET"). Esperaba que se compilara un ensamblaje por página, por lo que el resultado (ver Figura 8) fue una sorpresa total.



Fig. 8: compilar un sitio web ASP.NET en la plataforma Azure App Service

Esperaba ver un ensamblaje por página, porque pensé que estaba trabajando con el parámetro debug = true. Al leer acerca de la compilación por lotes, me di cuenta de que compila todas las páginas en el ensamblado contenido en un directorio específico. Así que creé dos directorios y puse los archivos .aspx en cada uno de ellos. PID no cambió, por lo que no hubo "arranque en frío" (Fig. 9).



Fig. 9: compilar un sitio web ASP.NET en la plataforma Azure App Service

Sin embargo, el sitio fue realmente recompilado en otro archivo binario, pero permaneció en el mismo directorio (ruta) (Fig. 10).



Fig. 10: compilar un sitio web ASP.NET en la plataforma Azure App Service

Volqué la memoria para verificar completamente la exactitud de mis conclusiones. Y, tan pronto como recurrí a la raíz del sitio y vi que todas las páginas del directorio estaban compiladas, me di cuenta de que mi hipótesis sobre la compilación por lotes estaba confirmada (Fig. 11).



Fig. 11: compilar un sitio web ASP.NET en la plataforma Azure App Service

Seguí el enlace "Directorio 1" y vi otra asamblea (Fig. 12).



Fig. 12: compilar un sitio web ASP.NET en la plataforma Azure App Service

Volví la memoria de nuevo, eliminé el volcado del módulo y vi que realmente corresponde a la página "Directorio 1" (Fig. 13).



Fig. 13: compilar un sitio web ASP.NET en la plataforma Azure App Service

Hice lo mismo para la página del Directorio 2 (Fig. 14 y 15).



Fig. 14: compilar un sitio web ASP.NET en la plataforma Azure App Service



Fig. 15: compilar un sitio web ASP.NET en la plataforma Azure App Service

También tuve la oportunidad de ir a las asambleas en SCM / KUDU (Fig. 16).



Fig. 16: compilar un sitio web ASP.NET en la plataforma Azure App Service

Tan pronto como descubrí el problema con el parámetro debug = true, todo encajó y fue una buena experiencia de aprendizaje. Espero que encuentre útil mi artículo.



Recursos utiles


Guía de arquitectura de aplicaciones en la nube


Adopte un enfoque estructurado para desarrollar aplicaciones en la nube. Este libro electrónico de 300 páginas sobre arquitectura de computación en la nube analiza las pautas de arquitectura, desarrollo e implementación que se aplican independientemente de la plataforma de nube que elija. Esta guía incluye pasos para:

  • Elegir el estilo de arquitectura de aplicaciones en la nube adecuado para su aplicación o solución;
  • selección de tecnologías apropiadas de computación y almacenamiento de datos;
  • implementando 10 principios de desarrollo para crear una aplicación escalable, resistente y manejable;
  • siguiendo los cinco principios de crear software de calidad que garantice el éxito de su aplicación en la nube;
  • Usando patrones de diseño diseñados para el problema que está tratando de resolver.


Descargar

Guía del desarrollador de Azure




En esta actualización de la Guía del desarrollador de Azure, verá cómo el conjunto completo de servicios para la plataforma de software de Azure satisface sus necesidades. Aquí encontrará información sobre enfoques arquitectónicos y las situaciones más comunes que surgen al crear aplicaciones en la nube.


Descargar

Conceptos básicos de Microsoft Azure


Este libro proporciona información importante sobre los servicios clave de Azure para desarrolladores y profesionales de TI que son nuevos en la computación en la nube. Se incluyen demostraciones paso a paso para ayudar al lector a comprender cómo comenzar con cada uno de los servicios clave. Cada capítulo es independiente, no es necesario realizar demostraciones prácticas de capítulos anteriores para comprender un capítulo en particular.

Los siguientes temas están cubiertos en este libro:

  • Comenzando con Azure;
  • Azure Application Service y aplicaciones web;
  • Máquinas virtuales;
  • Servicio de almacenamiento;
  • Bases de datos
  • Servicios adicionales de Azure.

Descargar

Enlaces utiles


Source: https://habr.com/ru/post/es421995/


All Articles