Distribuzione di un'applicazione runtime mediante Internet Explorer
Nelle applicazioni basate su Web è possibile utilizzare Microsoft Internet Explorer versione 5.5 o successiva per il download e l'esecuzione degli assembly. Un'applicazione basata su Web consente di eseguire il download di entrambi i tipi di file eseguibili portabili (PE) standard: EXE e DLL. Un documento HTML può fornire informazioni sugli assembly da scaricare, i percorsi degli assembly e il percorso di un file di configurazione che può contenere informazioni aggiuntive.
Internet Explorer consente di distribuire un'applicazione in modo vantaggioso, in quanto gli assembly vengono scaricati solo quando devono essere utilizzati. Se l'applicazione è costituita da più assembly, gli assembly vengono scaricati solo quando vi viene fatto riferimento. Questo processo automatico garantisce che il download iniziale di un'applicazione sia più rapido, dato che l'intera applicazione non deve essere scaricata e il client riceve solo il codice che utilizza.
Nota
Il codice distribuito via Internet dispone in genere del set di autorizzazioni Internet predefinito, impostato in base ai criteri di protezione, che consente al codice di eseguire solo un insieme limitato di funzioni. Per ulteriori informazioni sui criteri di protezione Internet predefiniti, vedere Criteri di protezione.
Impostazioni delle applicazioni basate su Web
Per impostazione predefinita Common Language Runtime crea un dominio applicazione per ciascun sito a cui si accede mediante Internet Explorer. I domini applicazione consentono di isolare le diverse applicazioni eseguite all'interno di un processo. La modalità con la quale vengono creati i domini applicazione influenza le autorizzazioni di cui gli assembly dispongono quando vengono eseguiti nel dominio. A ciascun dominio applicazione viene associata una prova URL, una base applicativa ed eventualmente un file di configurazione.
Prova URL
La prova URL è assegnata ad applicazioni distribuite utilizzando Microsoft Internet Explorer 5.5 o versione successiva. L'host di runtime utilizza questa prova URL per prendere decisioni basate sui criteri di protezione. Sebbene la prova URL sia associata sia agli assembly che costituiscono l'applicazione che al dominio applicazione creato dall'applicazione stessa, il formato della prova è differente in ciascun caso. Per un assembly la prova URL è il percorso URL completo al file dell'assembly principale. Ad esempio, un assembly che è parte di un'applicazione potrebbe avere la prova URL http://www.code.microsoft.com/myApp/myAssembly.dll. La prova URL per il dominio applicazione è equivalente alla prova del sito. Utilizzando l'esempio precedente, la prova URL del dominio applicazione sarà http://www.code.microsoft.com/.
Nota
Il percorso del file di configurazione dell'applicazione non influenza la prova URL del dominio applicazione.
File di configurazione
Le applicazioni Web distribuite tramite Internet Explorer possono utilizzare le informazioni memorizzate in un file di configurazione dell'applicazione. Tale file deve trovarsi sul server Web nella stessa directory del file eseguibile dell'applicazione. È necessario che il file di configurazione segua le convenzioni di denominazione dei file di configurazione, ovvero deve avere lo stesso nome del file eseguibile e l'estensione CONFIG. Un'applicazione denominata miaApplicazione.exe dovrebbe ad esempio avere un file di configurazione denominato miaApplicazione.exe.config.
Le applicazioni ASP.NET consentono di specificare le informazioni di configurazione mediante un file web.config. Le applicazioni Web possono fornire informazioni di configurazione nello stesso modo delle applicazioni ASP.NET e degli host eseguibili. Se un'applicazione contenuta in Internet Explorer dispone di un file di configurazione, il percorso del file verrà specificato in un tag <link> con la seguente sintassi:
<LINK REL="CONFIGURATION" HREF="[configuration file name]"></LINK>
In questo caso [nome file di configurazione] è il nome del file di configurazione, ad esempio:
<LINK REL="CONFIGURATION" HREF="two.dll.config"></LINK>
Per gli scenari di applicazioni Web di base, nei quali la pagina Web non fornisce un tag link per un file di configurazione, il runtime crea un dominio applicazione per ciascun sito. Vale a dire, se il documento HTML si trova sul sito http://www.code.microsoft.com/myApp/mypage.htm, il dominio applicazione verrà creato per tutto il sito http://www.code.microsoft.com. Sebbene questo scenario presenti alcuni vantaggi per l'autore del sito Web, tutte le pagine Web in cui vengono utilizzati assembly di codice gestito sul sito condividono lo stesso dominio applicazione poiché non è stato specificato alcun file di configurazione.
Se l'applicazione legge le informazioni da un file di configurazione, sarà necessario effettuare quanto segue:
Posizionare il file di configurazione nella stessa cartella del file eseguibile.
Permettere l'accesso anonimo al sito Web e la directory contenente il file di configurazione dovrà consentire l'esecuzione dello script.
In uno scenario più complesso, è possibile che sia necessario eseguire due o più applicazioni diverse sullo stesso sito mantenendole al contempo isolate tra loro. Per ottenere l'isolamento, l'autore delle pagine Web deve specificare un file di configurazione nel documento HTML. Tutte le pagine che fanno riferimento allo stesso file di configurazione vengono create all'interno dello stesso dominio applicazione. In questo modo, è possibile creare un dominio applicazione per ogni file di configurazione.
Nota
Il runtime non supporta il carattere "#" negli URL che specificano il percorso di un file di configurazione quando il tag <link> contiene un percorso relativo.
Base applicativa
ApplicationBase è una proprietà del dominio applicazione che specifica la directory utilizzata come directory principale durante la ricerca degli assembly da parte del runtime. Per impostazione predefinita, la proprietà ApplicationBase indica la radice del sito, ad esempio wwwroot. Se è presente un file di configurazione, ApplicationBase diventa il percorso di tale file. Il file di configurazione può contenere informazioni di configurazione specifiche per il codice in esecuzione nel dominio applicazione. Se su un computer sono presenti più siti, per impostazione predefinita ApplicationBase sarà il sito "predefinito" specificato nella porta 80.
Download di file eseguibili gestiti
Mentre la maggior parte delle applicazioni scaricate utilizzando il tag <object> rappresenta controlli dell'interfaccia utente visualizzati sulla pagina Web, il runtime supporta anche i due scenari illustrati di seguito per effettuare il download di file eseguibili gestiti.
Un utente digita nel browser l'URL di un file EXE gestito, ad esempio:
http://www.server.microsoft.com/MyWebSite/MyApp.exe.
Una pagina HTML contiene un collegamento a un file eseguibile gestito, ad esempio:
HREF="MyApp.exe".
In entrambi gli scenari, il runtime crea un nuovo dominio applicazione nel quale eseguire il file eseguibile. Per le successive richieste di assembly, la base applicativa viene impostata sul percorso del file eseguibile.
Il codice illustrato di seguito fa riferimento a myClass
:
<object id="myCtl"
classid="http://www.mycode.Microsoft.com/mycode.dll#myClass">
</object>
Gli assembly dipendenti che sono collegati in modo statico devono essere posizionati nella stessa directory dell'assembly chiamante quando quest'ultimo viene specificato utilizzando il tag <object>. Se, ad esempio, l'assembly myAssembly.dll viene specificato utilizzando il tag <object> e contiene un riferimento statico all'assembly myOtherAssembly.dll, quest'ultimo deve essere posizionato nella stessa directory di myAssembly.dll.
Nota
I file eseguibili di codice gestito distribuiti da Internet Explorer tramite un collegamento HREF non devono essere avviati con argomenti della riga di comando. Gli argomenti non vengono passati al file eseguibile.
Segnalazione degli errori
Il processo di download di codice utilizza le due impostazioni del Registro di sistema riportate di seguito per controllare la segnalazione degli errori dai file eseguibili del codice gestito distribuiti da Internet Explorer.
HKLM\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
HKCU\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
Entrambe le impostazioni utilizzano i valori riportati di seguito per specificare le modalità di segnalazione degli errori.
Valore | Descrizione |
---|---|
1 |
Le informazioni relative agli errori vengono inviate al flusso di output standard. |
2 |
Le informazioni relative agli errori vengono visualizzate all'utente. |
3 |
Le informazioni relative agli errori vengono inviate al flusso di output standard e visualizzate all'utente. |
Quando si esegue il debug di codice gestito distribuito in Internet Explorer, è possibile utilizzare i valori di tali impostazioni per ottenere informazioni dettagliate sugli errori relativi al download di codice. In questo modo sarà possibile, ad esempio, visualizzare informazioni relative all'analisi dello stack quando vengono generate eccezioni, invece di basarsi sul sistema di segnalazione degli errori offerto da Internet Explorer, progettato per gli utenti finali, non per gli sviluppatori.
Controlli contenuti in Internet Explorer
È possibile utilizzare Internet Explorer per contenere controlli creati con .NET Framework. È necessario che i controlli siano contenuti in una libreria con un'estensione dll. Per utilizzare lo stesso controllo Windows Form sia come autonomo che come contenuto in Internet Explorer e per funzionare in entrambi i casi, è necessario che la libreria abbia l'estensione dll.
Importante |
---|
Tutti i controlli gestiti memorizzati in Internet Explorer utilizzano l'ultima versione di Common Language Runtime installata nel computer. È pertanto possibile che in alcuni casi il controllo non venga eseguito sulla versione per cui è stato generato e in base agli stessi criteri di protezione originariamente definiti. Prima di eseguire un controllo gestito in una nuova versione di Common Language Runtime, è necessario aggiornare i criteri di protezione per tale versione. Questa impostazione si applica all'area di protezione, ma non ai file eseguibili gestiti scaricati. |
Nota
Quando si carica un controllo gestito, la lunghezza massima del valore dell'attributo classid dell'elemento <object> è 256 caratteri (MAX_PATH). Se la lunghezza supera il numero massimo di caratteri consentito, il controllo non verrà caricato ma non verranno generati errori. Ad esempio, il seguente valore dell'attributo classid è di lunghezza accettabile:
<object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">
Nota
Per ragioni di protezione, nelle pagine HTML non sono supportati i controlli gestiti che utilizzano il tag <object> e il protocollo di accesso ai file. Non è supportato, ad esempio, il tag <object> seguente:
<OBJECT classid="file:///c:/control.dll#control">
Individuazione di assembly dipendenti
Il processo utilizzato dal runtime per individuare gli assembly dipendenti per le applicazioni basate su Web è simile a quello utilizzato per le applicazioni non basate su Web. Il runtime esegue la ricerca degli assembly dipendenti privati utilizzando un percorso relativo a quello definito nella proprietà ApplicationBase. Per l'individuazione degli assembly privati, il runtime utilizza la proprietà ApplicationBase, il tag <private_binpath>, contenuto in un file di configurazione, e le regole di ricerca. Per verificare la presenza di assembly dipendenti, il runtime controlla anche l'URL in cui risiede l'assembly chiamante.
Firma di codice gestito con una firma Microsoft Authenticode
È possibile utilizzare Strumento firma digitale (Signcode.exe) per apporre una firma digitale Authenticode a un file. Se si desidera firmare un file sia con un nome sicuro che con una firma digitale Authenticode, sarà necessario assegnare per primo il nome sicuro. Se si assegna prima la firma Authenticode, non sarà possibile utilizzare il nome sicuro. Per ulteriori informazioni sulla firma dei file, vedere Considerazioni sulla protezione degli assembly. Per informazioni sulla firma dei file mediante Visual Studio 2005, vedere "Distribuzione e firma Authenticode" nella documentazione di Visual Studio 2005. Per ulteriori informazioni sulla tecnologia alla base della firma Authenticode, vedere la sezione relativa all'introduzione alla firma del codice nella documentazione di Platform SDK.
Vedere anche
Riferimenti
Strumento firma digitale (Signcode.exe)
Concetti
Scenari di distribuzione di applicazioni .NET Framework
Considerazioni sulla protezione degli assembly
Come il runtime individua gli assembly