Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questo articolo è specifico di .NET Framework. Non si applica alle implementazioni più recenti di .NET, incluse .NET 6 e versioni successive.
L'esecuzione side-by-side è la possibilità di eseguire più versioni di un'applicazione o di un componente nello stesso computer. È possibile avere più versioni di Common Language Runtime e più versioni di applicazioni e componenti che usano una versione del runtime nello stesso computer contemporaneamente.
La figura seguente mostra diverse applicazioni che usano due versioni diverse del runtime nello stesso computer. Le applicazioni A, B e C usano la versione di runtime 1.0, mentre l'applicazione D usa la versione di runtime 1.1.
.NET Framework è costituito da Common Language Runtime e da una raccolta di assembly che contengono i tipi di API. Il runtime e gli assembly .NET Framework vengono con versione separata. Ad esempio, la versione 4.0 del runtime è effettivamente la versione 4.0.319, mentre la versione 1.0 degli assembly .NET Framework è la versione 1.0.3300.0.
La figura seguente mostra diverse applicazioni che usano due versioni diverse di un componente nello stesso computer. L'applicazione A e B usano la versione 1.0 del componente mentre l'applicazione C usa la versione 2.0 dello stesso componente.
L'esecuzione side-by-side offre maggiore controllo sulle versioni di un componente a cui un'applicazione è associata e un maggiore controllo sulla versione del runtime usata da un'applicazione.
Vantaggi dell'esecuzione parallela
Prima di Windows XP e .NET Framework, si sono verificati conflitti di DLL perché le applicazioni non erano in grado di distinguere tra versioni incompatibili dello stesso codice. Le informazioni sul tipo contenute in una DLL sono state associate solo a un nome di file. Un'applicazione non aveva modo di sapere se i tipi contenuti in una DLL erano gli stessi tipi con cui è stata compilata l'applicazione. Di conseguenza, una nuova versione di un componente potrebbe sovrascrivere una versione precedente e interrompere le applicazioni.
L'esecuzione side-by-side e .NET Framework forniscono le funzionalità seguenti per eliminare i conflitti di DLL:
Assembly con nome forte.
L'esecuzione affiancata utilizza assembly con nome forte per associare informazioni sul tipo a una versione specifica di un assembly. Ciò impedisce a un'applicazione o a un componente di eseguire l'associazione a una versione non valida di un assembly. Gli assembly con nome sicuro consentono anche l'esistenza di più versioni di un file nello stesso computer e l'uso da parte delle applicazioni. Per ulteriori informazioni, vedere Strong-Named Assemblee.
Archiviazione del codice con consapevolezza delle versioni.
Il .NET Framework fornisce l'archiviazione del codice sensibile alle versioni nella Global Assembly Cache. La Global Assembly Cache è una cache di codice a livello di computer presente in tutti i computer con .NET Framework installato. Archivia i componenti in base alle informazioni sulla versione, sul linguaggio, e sull'informazione riguardante l'editore, e supporta diverse versioni di componenti e applicazioni. Per altre informazioni, vedere Global Assembly Cache.
Isolamento.
Con .NET Framework è possibile creare applicazioni e componenti eseguiti in isolamento. L'isolamento è un componente essenziale dell'esecuzione affiancata. Implica la conoscenza delle risorse usate e della condivisione delle risorse con sicurezza tra più versioni di un'applicazione o di un componente. L'isolamento include anche l'archiviazione di file in modo specifico per versione. Per altre informazioni sull'isolamento, vedere Linee guida per la creazione di componenti per l'esecuzione side-by-side.
Compatibilità delle versioni
Le versioni 1.0 e 1.1 di .NET Framework sono progettate per essere compatibili tra loro. Un'applicazione compilata con .NET Framework versione 1.0 deve essere eseguita nella versione 1.1 e un'applicazione compilata con .NET Framework versione 1.1 deve essere eseguita nella versione 1.0. Si noti, tuttavia, che le funzionalità api aggiunte nella versione 1.1 di .NET Framework non funzioneranno con la versione 1.0 di .NET Framework. Le applicazioni create con la versione 2.0 verranno eseguite solo nella versione 2.0. Le applicazioni versione 2.0 non verranno eseguite nella versione 1.1 o precedente.
Le versioni di .NET Framework vengono considerate come una singola unità costituita dal runtime e dagli assembly .NET Framework associati(unificazione dell'assembly). È possibile reindirizzare l'associazione di assembly per includere altre versioni degli assembly .NET Framework, ma l'override dell'associazione di assembly predefinita può essere rischiosa e deve essere testato rigorosamente prima della distribuzione.
Individuazione delle informazioni sulla versione del runtime
Le informazioni sulla versione di runtime con cui è stata compilata un'applicazione o un componente e le versioni del runtime richieste dall'applicazione vengono archiviate in due posizioni. Quando un'applicazione o un componente viene compilato, le informazioni sulla versione di runtime usata per compilarla vengono archiviate nell'eseguibile gestito. Le informazioni sulle versioni di runtime richieste dall'applicazione o dal componente vengono archiviate nel file di configurazione dell'applicazione.
Informazioni sulla versione di runtime nel file eseguibile gestito
L'intestazione del file eseguibile portabile (PE) di ogni applicazione gestita e componente contiene informazioni sulla versione di runtime con cui è stata compilata. Common Language Runtime usa queste informazioni per determinare la versione più probabile del runtime che l'applicazione deve eseguire.
Informazioni sulla versione del runtime nel file di configurazione dell'applicazione
Oltre alle informazioni nell'intestazione del file PE, un'applicazione può essere distribuita con un file di configurazione dell'applicazione che fornisce informazioni sulla versione di runtime. Il file di configurazione dell'applicazione è un file basato su XML creato dallo sviluppatore dell'applicazione e fornito con un'applicazione.
L'elemento<requiredRuntime> della <startup> sezione, se presente in questo file, specifica le versioni del runtime e le versioni di un componente supportate dall'applicazione. È anche possibile usare questo file nei test per testare la compatibilità di un'applicazione con versioni diverse del runtime.
Il codice non gestito, incluse le applicazioni COM e COM+, può avere file di configurazione dell'applicazione usati dal runtime per interagire con codice gestito. Il file di configurazione dell'applicazione influisce su qualsiasi codice gestito attivato tramite COM. Il file può specificare le versioni di runtime supportate, nonché i reindirizzamenti di assembly. Per impostazione predefinita, le applicazioni di interoperabilità COM che chiamano il codice gestito usano la versione più recente del runtime installato nel computer.
Per altre informazioni sui file di configurazione dell'applicazione, vedere Configurazione delle app.
Determinazione della versione del runtime da caricare
Common Language Runtime usa le informazioni seguenti per determinare quale versione del runtime caricare per un'applicazione:
Le versioni di runtime disponibili.
Versioni di runtime supportate da un'applicazione.
Versioni di runtime supportate
Il runtime usa il file di configurazione dell'applicazione e l'intestazione del file eseguibile portabile (PE) per determinare la versione del runtime supportata da un'applicazione. Se non è presente alcun file di configurazione dell'applicazione, il runtime carica la versione di runtime specificata nell'intestazione del file PE dell'applicazione, se tale versione è disponibile.
Se è presente un file di configurazione dell'applicazione, il runtime determina la versione di runtime appropriata da caricare in base ai risultati del processo seguente:
Il runtime esamina l'elemento
<supportedRuntime>Element nel file di configurazione dell'applicazione. Se sono presenti una o più versioni di runtime supportate specificate nell'elemento<supportedRuntime>, il runtime carica la versione di runtime specificata dal primo<supportedRuntime>elemento. Se questa versione non è disponibile, il runtime esamina l'elemento successivo<supportedRuntime>e tenta di caricare la versione di runtime specificata. Se questa versione di runtime non è disponibile, vengono esaminati gli elementi successivi<supportedRuntime>. Se nessuna delle versioni di runtime supportate è disponibile, il runtime non riesce a caricare una versione di runtime e visualizza un messaggio all'utente (vedere il passaggio 3).Il runtime legge l'intestazione del file PE del file eseguibile dell'applicazione. Se la versione di runtime specificata dall'intestazione del file PE è disponibile, il runtime carica tale versione. Se la versione di runtime specificata non è disponibile, il runtime cerca una versione di runtime determinata da Microsoft per essere compatibile con la versione di runtime nell'intestazione PE. Se tale versione non viene trovata, il processo continua con il passaggio 3.
Il runtime visualizza un messaggio che informa che la versione di runtime supportata dall'applicazione non è disponibile. Il runtime non viene caricato.
Annotazioni
È possibile eliminare la visualizzazione di questo messaggio utilizzando il valore NoGuiFromShim sotto la chiave del Registro di sistema HKLM\Software\Microsoft\. NETFramework o usando la variabile di ambiente COMPLUS_NoGuiFromShim. Ad esempio, è possibile eliminare il messaggio per le applicazioni che in genere non interagiscono con l'utente, ad esempio installazioni automatiche o servizi Windows. Quando il messaggio visualizzato viene eliminato, il runtime scrive un messaggio nel registro eventi. Impostare il valore del Registro di sistema NoGuiFromShim su 1 per eliminare questo messaggio per tutte le applicazioni in un computer. In alternativa, impostare la variabile di ambiente COMPLUS_NoGuiFromShim su 1 per eliminare il messaggio per le applicazioni in esecuzione in un particolare contesto utente.
Annotazioni
Dopo il caricamento di una versione di runtime, i reindirizzamenti di associazione di assembly possono specificare che una versione differente di un singolo assembly .NET Framework venga caricata. Questi reindirizzamenti di binding influiscono solo sull'assembly specifico reindirizzato.
Nomi di assembly parzialmente qualificati ed esecuzione affiancata
Poiché sono una potenziale causa di problemi fianco a fianco, i riferimenti ad assembly parzialmente qualificati possono essere usati solo per l'associazione agli assembly all'interno di una directory dell'applicazione. Evitare riferimenti ad assembly parzialmente qualificati nel tuo codice.
Per ridurre i riferimenti di assembly parzialmente qualificati nel codice, è possibile usare l'elemento <qualifyAssembly> in un file di configurazione dell'applicazione per qualificare completamente i riferimenti di assembly parzialmente qualificati che si verificano nel codice. Utilizzare l'elemento <qualifyAssembly> per specificare solo i campi non impostati nel riferimento parziale. L'identità dell'assembly elencata nell'attributo fullName deve contenere tutte le informazioni necessarie per qualificare completamente il nome dell'assembly: nome dell'assembly, chiave pubblica, cultura e versione.
Nell'esempio seguente viene illustrata la voce del file di configurazione dell'applicazione per qualificare completamente un assembly denominato myAssembly.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="myAssembly"
fullName="myAssembly,
version=1.0.0.0,
publicKeyToken=...,
culture=neutral"/>
</assemblyBinding>
Ogni volta che un'istruzione di caricamento dell'assembly fa riferimento a myAssembly, queste impostazioni del file di configurazione fanno sì che il runtime traduca automaticamente il riferimento parzialmente qualificato myAssembly in un riferimento completamente qualificato. Ad esempio, Assembly.Load("myAssembly") diventa Assembly.Load("myAssembly, version=1.0.0.0, publicKeyToken=..., culture=neutral").
Annotazioni
È possibile usare il LoadWithPartialName metodo per ignorare la restrizione Common Language Runtime che impedisce il caricamento di assembly parzialmente referenziati dalla Global Assembly Cache. Questo metodo deve essere usato solo negli scenari di remotizzazione perché può facilmente causare problemi nell'esecuzione parallela.
Argomenti correlati
| Titolo | Descrizione |
|---|---|
| Procedura: Abilitare e disabilitare il reindirizzamento automatico dell'associazione automatica | Viene descritto come associare un'applicazione a una versione specifica di un assembly. |
| Configurazione del binding di assembly per il reindirizzamento | Viene spiegato come reindirizzare i riferimenti di collegamento degli assembly a una versione specifica degli assembly del .NET Framework. |
| In-Process esecuzione parallela | Viene illustrato come usare l'attivazione side-by-side dell'host di runtime in-process per eseguire più versioni di CLR in un singolo processo. |
| Assembly in .NET | Fornisce una panoramica concettuale degli assembly. |
| Domini di applicazione | Fornisce una panoramica concettuale dei domini applicazione. |