Un assembly rappresenta il costituente fondamentale di un'applicazione .NET. È una collezione di funzionalità sviluppate e distribuite come una singola unità applicativa (uno o più file). Tutti i tipi e le risorse gestiti sono contrassegnati o come accessibili solo all'interno della propria unità implementativa o come esportati per essere utilizzati dal codice al di fuori di tale unità.

Gli assembly si autodescrivono tramite il proprio manifesto, che costituisce una parte integrante di ogni assembly.

Di fatto il manifesto:

• Stabilisce l'identità dell'assembly in termini di nome, versione, livello di condivisione tra applicazioni diverse, firma digitale.
• Definisce quali file (nome e file hash) costituiscono l'implementazione dell'assembly.
• Specifica le dipendenze in fase di compilazione da altri assembly.
• Specifica i tipi e le risorse che costituiscono l'assembly, inclusi quelli che vengono esportati dall'assembly.
• Specifica l'insieme dei permessi necessari al corretto funzionamento dell'assembly.

Queste informazioni sono utilizzate in fase di esecuzione per risolvere i riferimenti, potenziare i criteri di binding delle versioni e convalidare l'integrità degli assembly caricati. Il runtime può determinare e localizzare gli assembly per ogni oggetto in esecuzione, dal momento che ogni tipo viene caricato all'interno del contesto di un assembly. Gli assembly rappresentano, inoltre, l'unità cui vengono applicati i permessi di sicurezza per l'accesso al codice. L'evidenza di identità per ogni assembly viene considerata separatamente quando vengono determinati i permessi per acquisire il codice in esso contenuto.

In poche parole, gli assembly contengono informazioni relative a ciò da cui dipendono le informazioni in essi incluse. Il runtime deve preoccuparsi che tali dipendenze siano soddisfatte. Poiché il runtime è responsabile della gestione vera e propria delle applicazioni in esecuzione, il .NET Framework è in grado di eseguire due versioni della stessa componente side-by-side. La natura autodescrittiva degli assembly aiuta, inoltre, a rendere possibile l'installazione ad "impatto zero" e la distribuzione "no-touch".

È sempre stato possibile che più copie di una componente software risiedessero sullo stesso sistema. In passato, tuttavia, solamente una di queste copie poteva essere registrata a livello di sistema operativo o essere caricata per l'esecuzione - il criterio per la localizzazione ed il caricamento delle componenti era unico a livello di sistema. Grazie alla distribuzione side-by-side, il .NET Framework aggiunge l'infrastruttura necessaria a gestire i criteri che governano la localizzazione ed il caricamento delle componenti a livello di singola applicazione.

Le informazioni di configurazione di un'applicazione definiscono i percorsi di memorizzazione degli assembly, pertanto il runtime può caricare differenti versioni dello stesso assembly per due applicazioni distinte che girano contemporaneamente. Ciò elimina i problemi che derivano dall'incompatibilità tra le versioni delle componenti, migliorando la stabilità dell'intero sistema. Se necessario, gli amministratori possono aggiungere in fase di distribuzione informazioni sulla configurazione per gli assembly, come un diverso criterio di controllo dei conflitti di versione, senza perdere le informazioni originali fornite in fase di creazione.

Poiché gli assembly sono autodescrittivi, non è necessaria alcune registrazione esplicita a livello di sistema operativo. La distribuzione dell'applicazione può essere resa semplice come la copia di un file all'interno di una directory. Le informazioni sulla configurazione vengono memorizzate nei file XML che possono essere modificati utilizzando un qualsiasi editor di testo.

Di fatto un assembly è quindi l'unità funzionale per la condivisione ed il riuso di del codice nel Common Language Runtime. E' l'equivalente dei file JAR (Java Archive) in Java.

Fisicamente è una raccolta di file contenuta in archivi in formato .CAB o nel recentemente introdotto formato .MSI. Gli Assembly contenuti in un .CAB o in un .MSI sono chiamati assembly statici, e includono sia i tipi del .NET Framework (interfacce e classi) sia risorse per l'assembly (immagini bitmap o JPEG, altri file di risorse ecc.); inoltre includono metadati che eliminano la necessità di un file IDL (Interface Definition Language) necessari invece alla descrizione dei componenti COM.

Il CLR fornisce anche API utilizzate dai motori di scripting che creano assembly dinamici durante l'esecuzione degli script; questi assembly sono eseguiti direttamente senza essere salvati su disco.

Gli assembly sono un adattamento ma non una copia della tecnologia JAR di Java, che è stata migliorata sotto alcuni aspetti, ad esempio introducendo un sistema di gestione delle versioni. Tuttavia, dal momento che la piattaforma .NET è indissolubilmente legata ai sistemi operativi Windows, alcune caratteristiche di portabilità di JAR sono andate perdute.

Come i file JAR, anche gli assembly contengono una entità chiamata manifesto, che in questo caso hanno un ruolo più ampio. I manifesti sono metadati descriventi le correlazioni tra le entità contenute negli assembly come codice gestito, immagini e risorse multimediali. I manifesti inoltre forniscono informazioni sulle versioni delle entità.

Il manifesto invece rappresenta un descrittore per la distribuzione (Deployment Descriptor), ed ha una sintassi XML come gli altri metadati. I programmatori potranno trovare più di una similitudine con i deployment descriptor per le applicazioni EjB (Enterprise Java Beans) presenti in Java 2 Enterprise Edition.

Similmente al concetto di trusted lib di Java, gli assembly .NET possono essere disposti in un'area di sicurezza chiamata global assembly cache. Quest'area è l'equivalente dei trusted class path di Java. Solo gli amministratori di sistema possono installare o rimuovere gli assembly dalla global assembly cache. Inoltre esiste un'altra area riservata agli assembly transitori come quelli scaricati dalla rete chiamata dowloaded assembly cache. Gli assembly caricati dalla global assembly cache sono eseguiti fuori dalla sandbox e hanno un tempo di caricamento minore, oltre ad una maggior libertà di accesso alle risorse di sistema; al contrario quelli provenienti dalla downloaded assembly cache sono soggetti a maggiori controlli di sicurezza e quindi sono più lenti nel caricamento e nell'esecuzione, inoltre essendo eseguiti nella sandbox dispongono di privilegi di accesso minori.

In conclusione si può schematizzare il ruolo delle entità esaminate sino ad ora in questo modo: il sistema operativo può avere più applicazioni in esecuzione simultaneamente, ogni applicazione occupa un processo Win32 separato, e può contenere Application Domain multipli. Un Application Domain può essere costruito da più assembly.

 

.::^top^::.