Come fa IIS a sapere se sta servendo un sito Web o un progetto di applicazione Web?

Question

Comprendo che i progetti di siti Web compilano l'origine al volo e i progetti di applicazione Web compilano l'origine in una DLL (molto simile a ASP.Net 1.x).

Ma come viene specificata la differenza in IIS?

So che Visual Studio sa: ci sono diversi progetti per ognuno, ecc. Ma l'istanza in esecuzione (IIS + Framework) ha per sapere quale modello di compilazione viene utilizzato, giusto? Perché in che altro modo sa se compilare o meno al volo?

Una richiesta arriva, colpisce un file ASPX ... e come fa il processo a sapere se il file CS associato deve essere compilato (sito Web) o se è già stato fatto prima della distribuzione (applicazione Web)?

Sono solo curioso di sapere dove viene specificata questa differenza. Nel web.config da qualche parte?

Answer 1

C'è una sottile differenza nel file .aspx che troverete in questi tipi di progetto.

Se si guarda a un Sito Web del progetto si dovrebbe vedere qualcosa di simile ...

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

... dove il progetto di applicazione Web avrà file aspx con qualcosa di simile ...

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

Si noti che il primo ha un attributo CodeFile e il secondo come attributo CodeBehind. È qui che viene fatta la distinzione.

L'attributo CodeBehind NON viene utilizzato in fase di esecuzione. È lì per indicare a VS.NET dove risiede il codice e l'attributo Inherits indica al runtime quale classe deve cercare nei file binari.

L'attributo CodeFile è utilizzato in fase di esecuzione e viene utilizzato da aspnet_compiler.exe per generare codice, quindi l'attributo Inherits viene utilizzato come sopra.

Per maggiori informazioni su questi attributi, guarda qui ...

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

Ma per rispondere alla tua domanda "come sa di IIS?" la risposta è "non è così". ASP.NET lo sa.

si può dimostrare che questo è il caso nel modo seguente:

1. Creare una nuova applicazione web. Ciò includerà un Default.aspx e un Default.aspx.cs.

2. Aggiungere il seguente codice in Default.aspx.cs:

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

3. Compilare il progetto, eseguirlo, vedere il testo "ciao" appaiono in un browser.

4. Ora, modificare il codice in modo che appaia come questo, e salvare il file con estensione cs:

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

5. NON compilazione. Aggiorna il tuo browser. Continuerai a vedere "ciao" perché il codice compilato utilizza ancora questa stringa.

6. Ora, modificare l'attrib in Default.aspx da CodeBehind a CodeFile. Salva questo file.

7. Aggiorna il browser. Verrà visualizzato "addio".

8. Cambia "addio" nel tuo codice su "I believe!". Salva .aspx.cs ma non compilare.

9. aggiornare il browser, vedere "Io credo!", E danza intorno alla stanza enlightend :-)

Answer 2

Sono sicuro che il framework gestisce questo ed è trasparente per IIS.

Answer 3

Una volta compilato il sito Web o l'applicazione Web, non c'è alcuna differenza per il server web. I gestori .NET in IIS sempre:

1. Compila le pagine ASPX.
2. Jit gli assembly costruiti nell'area dei file temporanei.
3. Eseguire la richiesta

Negli scenari in cui il sito è compilato completamente in una singola DLL ci sono sia ancora single linea file ASPX che raccontano i gestori di .NET in IIS in cui per ottenere il codice. Oppure le pagine ASPX possono essere rimosse del tutto con alcune linee di configurazione aggiuntive nel web.conig.

Ma la risposta breve è in realtà una volta compilati, sono identici.

Answer 4

Tutto ciò che fa IIS è passare la richiesta in arrivo al gestore appropriato. Nel caso di un sito/applicazione ASP.NET è aspnet_isapi.dll. Il conduttore si occupa quindi di tutto da lì.