¿Cómo sabe IIS si está sirviendo un sitio web o un proyecto de aplicación web?

Question

Entiendo que los proyectos de sitios web compilan fuentes sobre la marcha, y los proyectos de aplicaciones web precompilan fuentes en una DLL (muy similar a ASP.Net 1.x).

Pero, ¿cómo se especifica la diferencia en IIS?

Sé que Visual Studio lo sabe, hay diferentes proyectos para cada uno, etc. Pero la instancia en ejecución (IIS + Framework) tiene para saber qué modelo de compilación se está utilizando, ¿no? Porque, ¿de qué otra forma sabe si compila sobre la marcha o no?

Aparece una solicitud, accede a un archivo ASPX ... y ¿cómo sabe el proceso si el archivo CS asociado debe compilarse (sitio web) o si ya se realizó antes del despliegue (aplicación web)?

Tengo curiosidad por saber dónde se especifica esta diferencia. En la web.config en algún lugar?

Answer 1

Hay una diferencia sutil en el archivo .aspx que encontrará en estos tipos de proyectos.

Si nos fijamos en la Página Web del proyecto debería ver algo como esto ...

<%@ Page Language="C#" AutoEventWireup="true" 
CodeFile="Default.aspx.cs" Inherits="_Default" %> 

... donde como el proyecto de aplicación Web tendrá archivos .aspx con algo como esto ...

<%@ Page Language="C#" AutoEventWireup="true" 
CodeBehind="Default.aspx.cs" Inherits="WebApplication2._Default" %> 

Observe que el primero tiene un atributo CodeFile y el segundo como un atributo CodeBehind. Aquí es donde se hace la distinción.

El atributo CodeBehind NO se usa en tiempo de ejecución: está ahí para decirle a VS.NET dónde vive el código, y el atributo Heredas le dice al tiempo de ejecución qué clase buscar en los archivos binarios.

El atributo CodeFile se utiliza en tiempo de ejecución, y es utilizado por aspnet_compiler.exe para generar código, y luego el atributo Heredas se usa como se indicó anteriormente.

Para obtener más información sobre estos atributos, mira aquí ...

http://msdn.microsoft.com/en-us/library/ydy4x04a.aspx

Pero para responder a su pregunta "¿cómo sabe IIS?" la respuesta es "no". ASP.NET sabe.

se puede demostrar que este es el caso de la siguiente manera:

1. Crear una nueva aplicación web. Esto incluirá un Default.aspx y un Default.aspx.cs.

2. Agregue el código siguiente en Default.aspx.cs:

   protected void Page_Load(object sender, EventArgs e) 
   { 
       Response.Write("hello"); 
   } 
   

3. compilar el proyecto, ejecutarlo, ver el texto "hola" aparecen en un navegador.

4. Ahora, cambiar el código para que se vea como este, y guardar el archivo .cs:

   protected void Page_Load(object sender, EventArgs e) 
   { 
       Response.Write("goodbye"); 
   } 
   

5. no compilan. Actualiza tu navegador Todavía verá "hola" porque el código compilado todavía usa esta cadena.

6. Ahora, cambie el attrib en Default.aspx desde CodeBehind a CodeFile. Guarde este archivo.

7. Actualice su navegador. Verás que se muestra "adiós".

8. Cambie "adiós" en su código a "¡Creo!". Guarde el archivo .aspx.cs pero no compile.

9. actualizar su navegador, ver "Creo!", Y bailar alrededor de la habitación enlightend :-)

Answer 2

Estoy bastante seguro de que el marco maneja esto y es transparente para IIS.

Answer 3

Una vez compilado el sitio web o la aplicación web, no hay diferencia para el servidor web. Los controladores .NET en IIS siempre:

1. Compile las páginas ASPX.
2. Jit los ensamblajes construidos en el área de archivos temporales.
3. Ejecutar la solicitud

En los escenarios en los que el sitio se compila por completo en un solo archivo DLL o bien hay todavía una sola línea archivos ASPX contando los manipuladores de .NET en IIS dónde obtener el código. O bien, las páginas ASPX se pueden eliminar por completo con algunas líneas de configuración adicionales en el web.conig.

Pero la respuesta breve es que una vez compilados son idénticos.

Answer 4

Todo lo que hace IIS es pasar la solicitud entrante al controlador apropiado. En el caso de un sitio/aplicación ASP.NET es aspnet_isapi.dll. El controlador se encarga de todo desde allí.