Strumento per la compilazione di ASP.NET (Aspnet_compiler.exe)
Lo strumento per la compilazione di ASP.NET (Aspnet_compiler.exe) consente di compilare un'applicazione Web ASP.NET sul posto o per la distribuzione in un percorso di destinazione, ad esempio un server di produzione. La compilazione sul posto contribuisce al miglioramento delle prestazioni dell'applicazione in quanto la prima richiesta effettuata dagli utenti finali all'applicazione di cui è in corso la compilazione non subisce alcun ritardo. La compilazione per la distribuzione può essere eseguita in due modi. Il primo comporta la rimozione di tutti i file di origine, ad esempio i file code-behind e di markup, l'altro invece conserva i file di markup.
Nota
Per informazioni su come trovare la versione corretta di Aspnet_compiler.exe, consultare Individuazione della versione corretta di Aspnet_compiler.exe più avanti in questo argomento.
aspnet_compiler [-?]
[-m metabasePath | -v virtualPath [-p physicalPath]]
[[-u] [-f] [-d] [-fixednames] targetDir]
[-c]
[-errorstack]
[-nologo]
[[-keyfile file | -keycontainer container ] [-aptca] [-delaysign]]
Opzioni
Opzione |
Oggetto di descrizione |
|---|---|
-m metabasePath |
Specifica il percorso completo della metabase IIS dell'applicazione da compilare. La metabase IIS è un archivio informazioni gerarchico utilizzato per la configurazione di IIS. Il percorso della metabase del sito Web IIS predefinito, ad esempio, è LM/W3SVC/1/ROOT. Non è possibile combinare questa opzione con le opzioni -v o -p. |
-v virtualPath |
Specifica il percorso virtuale dell'applicazione da compilare. Se viene specificata anche l'opzione -p, il valore del parametro physicalPath che l'accompagna viene utilizzato per individuare l'applicazione da compilare. In caso contrario, viene utilizzata la metabase IIS e si presuppone che i file di origine si trovino nel sito Web predefinito, specificato nel nodo della metabase LM/W3SVC/1/ROOT. Non è possibile combinare questa opzione con -m. |
-p physicalPath |
Specifica il percorso completo o il percorso del disco locale della directory radice contenente l'applicazione da compilare. Se l'opzione -p non è specificata, la metabase IIS viene utilizzata per trovare la directory. Questa opzione deve essere combinata con l'opzione -v, ma non può essere combinata con l'opzione -m. |
-u |
Specifica che Aspnet_compiler.exe deve creare un'applicazione precompilata che consenta aggiornamenti successivi di contenuti, come le pagine con estensione aspx. Se l'opzione viene omessa, l'applicazione ottenuta conterrà solo i file compilati e non potrà essere aggiornata sul server di distribuzione. È possibile aggiornare l'applicazione solo attraverso la modifica dei file di markup di origine e la ricompilazione. È necessario che venga incluso il parametro targetDir. Quando si utilizza questa opzione, i blocchi di codice nei file .aspx (ovvero, il codice presente negli elementi script o tra i tag <% e %>) non vengono compilati. Pertanto, se vi sono errori di compilazione in questi blocchi di codice, l'errore verrà visualizzato solo in fase di esecuzione, perché il file .aspx viene compilato solo in quel momento. È generalmente non sicuro utilizzare questa opzione per un sito che si basa sui blocchi di codice nei file .aspx. |
-f |
Specifica che lo strumento deve sovrascrivere i file esistenti nella directory targetDir e nelle relative sottodirectory. |
-d |
Esegue l'override delle impostazioni definite nei file di configurazione di origine dell'applicazione per imporre l'inclusione delle informazioni sul debug nell'applicazione compilata. In caso contrario, non viene creato alcun output di debug. Non è possibile utilizzare l'opzione -d per la compilazione sul posto, che invece si basa sulle impostazioni di configurazione per le opzioni di debug. |
targetDir |
Percorso di rete o percorso del disco locale della directory radice che conterrà l'applicazione compilata. Se il parametro targetDir non è incluso, l'applicazione viene compilata sul posto. |
-c |
Specifica che l'applicazione da compilare deve essere completamente rigenerata. I componenti che sono già stati compilati vengono compilati nuovamente. Se questa opzione viene omessa, vengono generate solo le parti dell'applicazione che sono state modificate dall'ultima compilazione. |
-errorstack |
Specifica che lo strumento deve includere informazioni sulla traccia dello stack se la compilazione dell'applicazione non riesce. |
-keyfile file |
Specifica che l'attributo AssemblyKeyFileAttribute, che indica il nome del file contenente la coppia di chiavi pubblica/privata utilizzata per generare un nome sicuro, deve essere applicato all'assembly compilato. Questa opzione deve essere combinata con -aptca. Se l'attributo è già applicato all'assembly nei file di codice, Aspnet_compiler.exe genera un'eccezione. |
-keycontainer container |
Specifica che l'attributo AssemblyKeyNameAttribute, che indica il nome del contenitore della coppia di chiavi pubblica/privata utilizzata per generare un nome sicuro, deve essere applicato all'assembly compilato. Questa opzione deve essere combinata con -aptca. Se l'attributo è già applicato all'assembly nei file di codice, Aspnet_compiler.exe genera un'eccezione. |
-aptca |
Specifica che l'attributo AllowPartiallyTrustedCallersAttribute, che consente ai chiamanti con attendibilità parziale di accedere a un assembly, deve essere applicato all'assembly con nome sicuro generato da Aspnet_compiler.exe. Questa opzione deve essere combinata con l'opzione -keyfile o -keycontainer. Se l'attributo è già applicato all'assembly nei file di codice, Aspnet_compiler.exe genera un'eccezione. |
-delaysign |
Specifica che l'attributo AssemblyDelaySignAttribute, che indica che un assembly deve essere firmato con il token di chiave pubblica anziché con la coppia di chiavi pubblica/privata, deve essere applicato all'assembly generato. Questa opzione deve essere combinata con l'opzione -keyfile o -keycontainer. Se l'attributo è già applicato all'assembly nei file di codice, Aspnet_compiler.exe genera un'eccezione. Se si utilizza l'opzione -delaysign, il codice prodotto da Aspnet_compilier.exe può essere eseguito prima della firma del codice. È necessario verificare che il codice sia protetto da utenti malintenzionati prima del completamento della firma. |
-fixednames |
Specifica che è necessario generare un assembly per ogni pagina dell'applicazione. Ogni assembly viene denominato con il percorso virtuale della pagina originale, a meno che il nome superi il limite massimo previsto dal sistema operativo per i nomi file. In tal caso, viene generato un hash da utilizzare per il nome dell'assembly. Non è possibile utilizzare l'opzione -fixednames per la compilazione sul posto, che invece si basa sulle impostazioni di configurazione per la modalità batch di compilazione. |
-nologo |
Non visualizza le informazioni sul copyright. |
-? |
Visualizza la sintassi e le opzioni dei comandi dello strumento. |
Note
Esistono due versioni dello strumento per la compilazione di ASP.NET:
La versione fornita con .NET Framework 2.0. Utilizzare questa versione per le applicazioni Web distribuite nei pool di applicazioni associati a CLR .NET Framework 2.0. Le applicazioni Web possono utilizzare come destinazione .NET Framework 2.0, .NET Framework 3.0 o .NET Framework 3.5.
La versione fornita con .NET Framework 4. Utilizzare questa versione per le applicazioni Web distribuite nei pool di applicazioni associati a CLR .NET Framework 4. Le applicazioni Web possono utilizzare come destinazione .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, o .NET Framework 4. Quando questa versione viene utilizzata per siti Web con destinazione a .NET Framework 2.0, .NET Framework 3.0, o .NET Framework 3.5, fornisce una migliore segnalazione di errori rispetto alla versione di .NET Framework 2.0.
Per ulteriori informazioni su come sviluppare, compilare e distribuire siti Web destinati a versioni specifiche di .NET Framework, vedere Multitargeting di .NET Framework per progetti Web ASP.NET e Panoramica sull'esecuzione side-by-side in ASP.NET. Per le informazioni sulla modalità in cui lo strumento di compilazione ASP.NET determina qual è la versione di .NET Framework di destinazione per il sito Web, vedere la proprietà BuildManager.TargetFramework.
Lo strumento per la compilazione di ASP.NET può essere utilizzato in due modi: per la compilazione sul posto e la compilazione per la distribuzione, in cui viene specificata una directory di output di destinazione. Nelle sezioni seguenti vengono descritti i due scenari.
Compilazione di un'applicazione sul posto
Lo strumento per la compilazione di ASP.NET consente di compilare un'applicazione sul posto, ovvero imitare l'esecuzione di più richieste all'applicazione, determinando in questo modo una normale compilazione. Gli utenti di un sito precompilato non subiscono alcun ritardo causato dalla compilazione della pagina in occasione della prima richiesta.
Se si utilizza un account rappresentato, è necessario che sia l'account che l'account utente di accesso dispongano dell'accesso in lettura alla destinazione affinché la precompilazione abbia esito positivo.
Quando si precompila un sito sul posto, vengono applicate le condizioni seguenti:
Il sito conserva i rispettivi file e la struttura delle directory.
È necessario disporre di compilatori per tutti i linguaggi di programmazione utilizzati dal sito sul server.
Se la compilazione di un file non riesce, l'errore di compilazione si estende a tutto il sito.
Dopo aver aggiunto a un'applicazione nuovi file di origine, è possibile anche ricompilarla sul posto. Lo strumento compila solo i file nuovi o modificati, a meno che non si includa l'opzione -c.
Nota
Quando si compila un'applicazione contenente un'applicazione annidata, quest'ultima non viene compilata erichiede una compilazione separata.
Nota
La compilazione di un'applicazione Web che include pagine master può non riuscire se l'applicazione viene compilata come sito aggiornabile e si verifica un conflitto di ridenominazione.Tale conflitto può verificarsi se il nome della pagina master coincide con il nome dello spazio dei nomi di una pagina contenuto derivata dalla pagina master.La relazione di ereditarietà viene stabilita dall'attributo Inherits della direttiva @ Page.Per risolvere il problema, è possibile modificare il nome della classe della pagina master o modificare il nome dello spazio dei nomi, in alternativa è possibile compilare l'applicazione come non aggiornabile.
Nota
Se si utilizza la versione .NET Framework 4 dello strumento per precompilare un sito Web sul posto, e se il sito viene destinato a una versione precedente di .NET Framework ed è associato a un pool di applicazioni destinate a .NET Framework 2.0 CLR, la prima richiesta all'applicazione Web provocherà la compilazione dinamica come se il sito non fosse stato precompilato.Dipende dal fatto che il compilatore della riga di comando esegue la compilazione nelle cartelle temporanee di .NET Framework 4 non riconosciute dal CLR di .NET Framework 2.0.
Compilazione di un'applicazione per la distribuzione
Per compilare un'applicazione per la distribuzione, ovvero una compilazione in un percorso di destinazione, è necessario specificare il parametro targetDir che può rappresentare il percorso finale dell'applicazione Web. In alternativa, l'applicazione compilata può essere ulteriormente distribuita.
Se si utilizza l'opzione -u, l'applicazione viene compilata in modo da apportare modifiche a determinati file dell'applicazione compilata senza la necessità di ricompilarla. Aspnet_compiler.exe opera una distinzione tra tipi di file statici e dinamici e li gestisce in modo diverso quando crea l'applicazione risultante.
I file statici, tra cui quelli con estensione css, gif, htm, html, jpg, js e così via, sono una tipologia di file a cui non è associato un compilatore o un provider di generazione. Tali file vengono semplicemente copiati nel percorso di destinazione e conservano la propria posizione nella struttura delle directory.
I file dinamici, tra cui quelli con estensioni specifiche di ASP.NET, ad esempio asax, ascx, ashx, aspx, browser, master e così via, sono una tipologia di file a cui invece viene associato un compilatore o un provider di generazione. Lo strumento per la compilazione di ASP.NET genera assembly provenienti da questo tipo di file. Se l'opzione -u viene omessa, vengono creati anche file con estensione COMPILED che associano i file di origine originali al rispettivo assembly. Per garantire che la struttura delle directory dell'origine dell'applicazione sia conservata, vengono generati file segnaposto nei percorsi corrispondenti dell'applicazione di destinazione.
È necessario utilizzare l'opzione -u per indicare che il contenuto dell'applicazione compilata può essere modificato. In caso contrario, le modifiche successive vengono ignorate o causano errori di run-time.
Nella tabella riportata di seguito viene illustrato in che modo lo strumento per la compilazione di ASP.NET gestisce diversi tipi di file quando è inclusa l'opzione -u.
Tipo file |
Azione del compilatore |
|---|---|
ascx, aspx, master |
Questi file sono suddivisi in markup e codice sorgente, in cui sono inclusi file code-behind. Il codice sorgente viene compilato negli assembly, con nomi derivati dall'algoritmo di hash, e gli assembly vengono inseriti nella directory Bin. L'eventuale codice inline, ovvero il codice racchiuso tra elementi <script runat="server">, è incluso con il markup e non viene compilato. Nuovi file con lo stesso nome dei file di origine vengono creati per contenere il markup e vengono quindi inseriti nelle directory di output corrispondenti. |
ashx, asmx |
Questi file non vengono compilati e vengono spostati nelle directory di output così come sono, senza essere compilati. Per far sì che il codice di gestione venga compilato, inserirlo nei file del codice sorgente nella directory App_Code. |
cs, vb, jsl, cpp (senza includere i file code-behind relativi ai tipi di file elencati in precedenza) |
Questi file vengono compilati e inclusi come risorsa negli assembly che ad essi fanno riferimento. I file di origine non vengono copiati nella directory di output. Se a un file di codice non viene fatto riferimento, non viene compilato. |
Tipi di file personalizzati |
Questi file non vengono compilati, ma vengono copiati nelle directory di output corrispondenti. |
File di codice sorgente nella sottodirectory App_Code |
Questi file vengono compilati negli assembly e inseriti nella directory Bin. .gif "Nota") Nota
I tipi di file statici nella directory App_Code non vengono copiati nelle directory di output.
|
File con estensione resx e resource nella sottodirectory App_GlobalResources |
Questi file vengono compilati negli assembly e inseriti nella directory Bin. All'interno della directory di output principale non viene creata alcuna sottodirectory App_GlobalResources e nessun file con estensione resx o resources che si trova nella directory di origine viene copiato nelle directory di output. Nota
I file di risorse nella sottodirectory App_GlocalResources vengono compilati negli assembly prima della compilazione del codice nella sottodirectory App_Code.La modifica dei file di risorse dopo la compilazione non è supportata.
|
File con estensione resx e resource nella sottodirectory App_LocalResources |
Questi file non vengono compilati e sono copiati nelle directory di output corrispondenti. |
File con estensione skin nella sottodirectory App_Themes |
I file con estensione skin e i file di tema statici non vengono compilati ma vengono copiati nelle directory di output corrispondenti. |
BROWSER Web.config Tipi di file statici Assembly già presenti nella directory Bin |
Questi file vengono copiati così come sono nelle directory di output. |
Nella tabella riportata di seguito viene illustrato in che modo lo strumento per la compilazione di ASP.NET gestisce diversi tipi di file quando viene omessa l'opzione -u.
Nota
Non viene visualizzato alcun avviso per impedire la modifica del codice sorgente di un'applicazione compilata.
Tipo file |
Azione del compilatore |
|---|---|
aspx, asmx, ashx, master |
I file vengono suddivisi in markup e codice sorgente, che include i file code-behind e il codice racchiuso tra elementi <script runat="server">. Il codice sorgente viene compilato negli assembly, con nomi derivati da un algoritmo di hash. Gli assembly ottenuti vengono inseriti nella directory Bin. L'eventuale codice inline, ovvero il codice racchiuso tra le parentesi <% e %>, è incluso con il markup e non viene compilato. Il compilatore crea nuovi file per contenere il markup con lo stesso nome dei file di origine. I file ottenuti vengono inseriti nella directory Bin. Vengono inoltre creati file con lo stesso nome dei file di origine ma con estensione COMPILED, contenenti informazioni sul mapping. I file COMPILED vengono inseriti nelle directory di output corrispondenti al percorso originale dei file di origine. |
ASCX |
Tali file vengono suddivisi in markup e codice sorgente. Il codice sorgente viene compilato negli assembly e inserito nella directory Bin, con nomi derivati da un algoritmo di hash. Non viene generato alcun file di markup. |
cs, vb, jsl, cpp (senza includere i file code-behind relativi ai tipi di file elencati in precedenza) |
Il codice sorgente cui fanno riferimento gli assembly generati da file con estensione ascx, ashx o aspx viene compilato negli assembly e inserito nella directory Bin. Non viene copiato alcun file di origine. |
Tipi di file personalizzati |
Questi file vengono compilati come file dinamici. A seconda del tipo di file su cui si basano, il compilatore può inserire file di mapping nelle directory di output. |
File nella sottodirectory App_Code |
I file di codice sorgente inclusi in questa sottodirectory vengono compilati negli assembly e inseriti nella directory Bin. Nota
I tipi di file statici nella directory App_Code non vengono copiati nelle directory di output.
|
File nella sottodirectory App_GlobalResources |
Questi file vengono compilati negli assembly e inseriti nella directory Bin. All'interno della directory di output principale non viene creata alcuna sottodirectory App_GlobalResources. Se nel file di configurazione è specificato appliesTo="All", i file con estensione resx e resources vengono copiati nelle directory di output. Non vengono copiati se ad essi fa riferimento un BuildProvider. |
File con estensione resx e resource nella sottodirectory App_LocalResources |
Questi file vengono compilati negli assembly con nomi univoci e inseriti nella directory Bin. Nessun file con estensione resx o resource viene copiato nelle directory di output. |
File con estensione skin nella sottodirectory App_Themes |
I temi vengono compilati negli assembly e inseriti nella directory Bin. File stub vengono creati per i file con estensione skin e inseriti nella directory di output corrispondente. I file statici, ad esempio quelli con estensione css, vengono copiati nelle directory di output. |
BROWSER Web.config Tipi di file statici Assembly già presenti nella directory Bin |
Questi file vengono copiati così come sono nella directory di output. |
Nomi fissi degli assembly
Alcuni scenari, ad esempio la distribuzione di un'applicazione Web mediante MSI Windows Installer, richiedono l'utilizzo di nomi file e contenuti uniformi, nonché di strutture di directory uniformi, per identificare gli assembly o le impostazioni di configurazione per gli aggiornamenti. In questi casi è possibile utilizzare l'opzione -fixednames per specificare che lo strumento per la compilazione di ASP.NET deve compilare un assembly per ogni file di origine anziché utilizzare quello in cui più pagine vengono compilate negli assembly. Poiché questa opzione può determinare l'utilizzo di gran numero di assembly, è necessario utilizzarla con cautela per non causare problemi di scalabilità.
Compilazione con nome sicuro
Le opzioni -aptca, -delaysign -keycontainer e -keyfile consentono di utilizzare Aspnet_compiler.exe per creare assembly con nomi sicuri senza utilizzare lo Sn.exe (strumento Nome sicuro) separatamente. Tali opzioni corrispondono, rispettivamente, a AllowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute e AssemblyKeyFileAttribute. Poiché ognuna di esse applica l'attributo corrispondente all'assembly compilato, e poiché gli attributi sono contrassegnati con un AttributeUsageAttribute la cui proprietà AllowMultiple è impostata su false, la compilazione non riesce se si utilizzano queste chiavi sul codice sorgente già contrassegnato con uno degli attributi.
Classi ASP.NET associate
Diverse classi nello spazio dei nomi System.Web.Compilation consentono al codice di accedere o di richiamare Aspnet_compiler.exe al di fuori dell'ambiente IIS. La classe ClientBuildManager fornisce il metodo PrecompileApplication per compilare un'applicazione. La classe ClientBuildManager funziona anche con la classe ClientBuildManagerParameter, che consente di specificare PrecompilationFlags che corrispondono alle opzioni utilizzate da questo strumento e, analogamente, per specificare chiavi con nomi sicuri.
Esempi
Il comando seguente viene utilizzato per compilare l'applicazione WebApplication1 sul posto:
Aspnet_compiler -v /WebApplication1
Il comando seguente viene utilizzato per compilare l'applicazione WebApplication1 sul posto e lo strumento aggiunge informazioni di traccia dello stack qualora debbano essere segnalati gli errori.
Aspnet_compiler -v /WebApplication1 -errorstack
Il comando riportato di seguito consente di compilare l'applicazione WebApplication1 per la distribuzione, utilizzando il percorso fisico della directory. Aggiunge inoltre due attributi agli assembly di output. Utilizza l'opzione -keyfile per aggiungere un attributo AssemblyKeyFileAttribute che specifica che nel file Key.sn sono contenute le informazioni sulla coppia di chiavi pubblica/privata che lo strumento deve utilizzare per assegnare nomi sicuri agli assembly generati. Il comando utilizza inoltre l'opzione -aptca per aggiungere un attributo AllowPartiallyTrustedCallersAttribute agli assembly generati. L'applicazione Web compilata viene creata nella directory c:\Destinazioneapplicazione
Aspnet_compiler -v /WebApplication1 -p "c:\Documents and Settings\Default\My Documents\MyWebApplications\WebApplication1" -keyfile "c:\Documents and Settings\Default\My Documents\Key.sn" -aptca c:\applicationTarget
Il comando riportato di seguito consente di compilare il servizio WebService2 nel percorso della metabase predefinito sovrascrivendo la directory di destinazione SampleWebService con l'applicazione compilata.
Aspnet_compiler -m /LM/W3SVC/1/ROOT/WebService2 -f c:\InetPub\wwwroot\SampleWebService
Individuazione della versione corretta di Aspnet_compiler.exe
Lo strumento Aspnet_compiler.exe viene installato nella directory di Microsoft.NET Framework. Se nel computer sono in esecuzione più versioni di .NET Framework in modalità side-by-side, potrebbero essere installate più versioni dello strumento. Nella tabella seguente sono elencati i percorsi di installazione dello strumento per diverse versioni di .NET Framework.
Versione di .NET Framework |
Percorso del file Aspnet_compiler.exe |
|---|---|
.NET Framework versione 2.0, versione 3.0 e versione 3.5 (sistemi a 32 bit) |
%windir%\Microsoft.NET\Framework\v2.0.50727 |
.NET Framework versione 2.0, versione 3.0 e versione 3.5 (sistemi a 64 bit) |
%windir%\Microsoft.NET\Framework64\v2.0.50727 |
.NET Framework versione 4 (sistemi a 32 bit) |
%windir%\Microsoft.NET\Framework\v4.0.30319 |
.NET Framework versione 4 (sistemi a 64 bit) |
%windir%\Microsoft.NET\Framework64\v4.0.30319 |
Vedere anche
Riferimenti
AllowPartiallyTrustedCallersAttribute
Sn.exe (strumento Nome sicuro)
Strumento di ASP.NET per la registrazione di IIS (Aspnet_regiis.exe)
Concetti
Ritardo della firma di un assembly
Multitargeting di .NET Framework per progetti Web ASP.NET
Panoramica sull'esecuzione side-by-side in ASP.NET