Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original.
Traducción
Original
Personas que lo han encontrado útil: 0 de 1 - Valorar este tema

Descripción de la compilación dinámica de ASP.NET

Para que la aplicación Web atienda las solicitudes, ASP.NET debe analizar y compilar primero el código de la aplicación Web en uno o varios ensamblados. Cuando se compila el código, se traduce en una representación independiente del lenguaje y de la CPU llamado Lenguaje intermedio de Microsoft (MSIL). En tiempo de ejecución, MSIL se ejecuta en el contexto de .NET Framework, que traduce MSIL en instrucciones específicas de la CPU para el procesador en el equipo que ejecuta la aplicación.

La compilación dinámica de ASP.NET permite modificar el código fuente sin tener que compilarlo explícitamente antes de implementar la aplicación web. Si modifica un archivo de código fuente, ASP.NET lo vuelve a compilar automáticamente y actualiza todos los recursos vinculados. No es necesario reiniciar el servidor IIS para que los cambios se apliquen, a no ser que se modifique la sección <processModel>.

Puede extender el sistema de compilación de ASP.NET creando proveedores de compilación personalizados para nuevos tipos de archivo que se invoquen durante la compilación.

De forma predeterminada, las páginas Web ASP.NET y los archivos de código se compilan de forma dinámica la primera vez que los usuarios solicitan un recurso, como una página de ASP.NET (archivo. aspx), de un sitio Web. Una vez compiladas las páginas y los archivos de código por primera vez, los recursos compilados se almacenan en la caché para que las siguientes veces que solicite la misma página sea lo más eficaz posible.

ASP.NET admite la compilación dinámica de páginas ASP.NET (archivos .aspx), servicios Web ASP.NET (archivos .asmx), controladores HTTP de ASP.NET (archivos .ashx) y archivos de aplicación ASP.NET (Global.asax), además de otros archivos, como código fuente y archivos de clases. Para obtener más información sobre los tipos de archivos de ASP.NET, consulte Tipos de archivos de proyectos web ASP.NET. Para obtener más información sobre el proceso de compilación de ASP.NET, consulte la sección "Ciclo de vida de la compilación" de Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y 6.0.

Cualquiera cambio efectuado en un archivo compilado dinámicamente invalidará de forma automática el ensamblado compilado almacenado en caché del archivo y activará la recompilación de todos los recursos afectados. La próxima vez que se realice una solicitud en el código, ASP.NET reconocerá que el código ha cambiado y volverá a compilar los recursos afectados de la aplicación Web. Este sistema le permite desarrollar rápidamente las aplicaciones con una carga de procesamiento de compilación mínima. (Tenga en cuenta que las implicaciones de los cambios realizados en los recursos pueden oscilar entre tener que volver a compilar una sola página y volver a compilar todo el sitio web).

Cuando se realiza la primera solicitud en una aplicación, ASP.NET compila los archivos en un orden específico. Los primeros elementos que se van a compilar se denominan elementos de nivel superior. Después de la primera solicitud, se vuelven a compilar los elementos de nivel superior sólo si cambia una dependencia.

Los elementos de nivel superior incluyen la carpeta App_GlobalResources, la carpeta App_WebResources, las propiedades del perfil, la carpeta App_Code y el archivo Global.asax. Una vez compilados los elementos de nivel superior, ASP.NET compila los demás elementos. Estos elementos incluyen la carpeta App_LocalResources, páginas ASP.NET individuales (archivos .aspx), controles de usuario ASP.NET (archivos .ascx), controladores HTTP de ASP.NET (archivos .ashx) y módulos HTTP de ASP.NET (archivos .asmx), además de temas, páginas maestras y otros archivos de código fuente.

Para obtener más información, consulte Estructura de carpetas de proyectos web de ASP.NET y la sección "Ciclo de vida de la compilación" de Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y 6.0.

Al compilar el código, los ensamblados resultantes se almacenan en memoria caché en una carpeta del servidor. Esta carpeta requiere los permisos adecuados para que el código se compile y se ejecute correctamente. Puede configurar la ubicación de la carpeta de compilación y los permisos con los que se compila y funciona el código.

Ubicación de la carpeta de compilación

De forma predeterminada, al compilar una aplicación Web, el código compilado se coloca en la carpeta de archivos temporales de ASP.NET. Esta carpeta es un subdirectorio de la ubicación en la que instaló .NET Framework. Normalmente, la ubicación es la siguiente:

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files

Permisos necesarios en la carpeta de compilación

El proceso de instalación de .NET crea la carpeta de archivos temporales de ASP.NET y asigna permisos a la cuenta de usuario local de ASP.NET, que tiene los permisos con un nivel alto de confianza necesarios para tener acceso al código compilado. Si modifica su configuración o las opciones de su cuenta, debe asegurarse de que la cuenta que utiliza tiene permisos con un nivel alto de confianza en la cuenta de archivos temporales de ASP.NET. Para obtener detalles adicionales, consulte Cómo: Ejecutar el proceso de trabajo en una cuenta de usuario.

Capacidad de configuración de la carpeta de compilación

ASP.NET crea una única subcarpeta bajo la carpeta de archivos temporales de ASP.NET para cada aplicación. Puede configurar la ubicación raíz mediante el atributo tempDirectory de la sección de compilación del archivo de configuración. Este atributo opcional permite especificar el directorio que se va a utilizar para el almacenamiento de los archivos temporales durante la compilación. El valor predeterminado es una cadena vacía (""). Si el valor es una cadena vacía y el proceso actual tiene los permisos de acceso necesarios, los archivos se almacenan en el directorio siguiente:

%FrameworkInstallLocation%\Temporary ASP.NET Files

Para obtener más información, consulte Elemento compilation (Esquema de configuración de ASP.NET) y la propiedad TempDirectory de CompilationSection.

ASP.NET 2.0 admite varios lenguajes de programación en la misma aplicación Web. En el directorio App_Code, puede especificar una subcarpeta para cada lenguaje, como C# y Visual Basic. ASP.NET creará un ensamblado independiente para cada subcarpeta. Para obtener más información, vea Carpetas de código compartido en proyectos web ASP.NET y Tutorial: Usar varios lenguajes de programación en un proyecto de sitio web.

De forma predeterminada, cuando se realiza algún cambio en un archivo de nivel superior de un sitio web, se vuelve a compilar todo el sitio. Entre los archivos de nivel superior se encuentran el archivo global.asax y todos los archivos de las carpetas bin y App_Code. El procedimiento más seguro consiste en volver a compilarlo todo cuando cambia uno de estos archivos porque los demás archivos del sitio, como archivos .aspx y .ascx, pueden hacer referencia a los objetos creados por código en los archivos de nivel superior.

Si bien la recompilación total es la solución apropiada para la mayoría de las aplicaciones, puede dar lugar a que una aplicación de tamaño muy grande no esté disponible durante un amplio período de tiempo, incluso si los cambios que se han realizado son pequeños. Si la aplicación es bastante grande, es posible que deje de estar disponible durante cinco a diez minutos o más después de que se realice una modificación.

Si desea poder cambiar los archivos de nivel superior sin tener que volver a compilar todo el sitio, puede establecer en true el atributo optimizeCompilations del elemento compilation en el archivo Web.config. Si el valor de optimizeCompilations es true, al cambiar un archivo de nivel superior, solo se vuelven a compilar los archivos afectados. Este procedimiento permite ahorrar tiempo pero puede generar errores en tiempo de ejecución según el tipo de cambio que se realice en el archivo de nivel superior.

Normalmente, los siguientes tipos de cambios son seguros:

  • Cambio de un método de implementación. Dado que la firma no cambia, las páginas compiladas con la versión anterior pueden llamar al método sin que se inicie ninguna excepción.

  • Adición de nuevos métodos o properties. Dado que estos métodos o propiedades no existían anteriormente, las páginas ya compiladas no harán referencia a los mismos y no se iniciará ninguna excepción.

  • Adición de un atributo de CLR a un miembro existente. Se trata de un escenario típico de datos dinámicos en el que se agregan atributos como DisplayName a las propiedades. Dado que los atributos de CLR se detectan en tiempo de ejecución a través de la reflexión, no es necesario volver a compilar las páginas existentes.

Los siguientes tipos de cambios pueden generar excepciones en tiempo de ejecución:

  • Cambio de nombre o eliminación de métodos o properties. Se iniciará una excepción si una página compilada hace referencia al miembro afectado.

  • Cambio de la firma de un método o del tipo de una propiedad. Se iniciará una excepción si una página compilada hace referencia al miembro afectado. Algunos cambios de firma no generarán errores de compilación ni errores en tiempo de ejecución si se vuelve a compilar todo el sitio. Por ejemplo, el código Response.Write(ClassA.MethodA() en una página .aspx compilará y se ejecutará correctamente independientemente de si MethodA devuelve un valor de tipo int o short. Sin embargo, si la página .aspx ya está compilada y se cambia de int a short el tipo de valor devuelto de MethodA sin volver a compilar, se iniciará una excepción en tiempo de ejecución porque el código compilado espera la firma int.

Si desea utilizar el atributo optimizeCompilations para minimizar el tiempo de la compilación dinámica, deberá revisar atentamente cada cambio que realice en los archivos de nivel superior de un sitio y, si hay algún cambio que no sea seguro, deberá quitar temporalmente el atributo optimizeCompilations o establecer su valor en false.

Hay algunas funciones que no proporciona la compilación dinámica. La compilación dinámica puede implicar un tiempo de respuesta inicial más lento para los usuarios, porque las páginas y los archivos de código se deben compilar la primera vez que se solicitan. Esto puede constituir un problema especialmente en sitios grandes que se actualizan con frecuencia. La compilación dinámica no proporciona ningún medio de identificar los errores de tiempo de compilación antes de que los usuarios tengan acceso a un sitio. Además, la compilación dinámica no proporciona la capacidad de crear una versión compilada del sitio que se pueda implementar en un servidor de producción sin el código fuente. Si alguna de estas limitaciones suponen un problema para sus aplicaciones Web, puede precompilar su sitio Web. Para obtener información detallada, consulte Información general sobre la precompilación de ASP.NET.

¿Te ha resultado útil?
(Caracteres restantes: 1500)

Adiciones de comunidad

AGREGAR
© 2013 Microsoft. Reservados todos los derechos.