.NET

Da Skypedia.
Lo schema di funzionamento di .NET
Se COM e CORBA utilizzavano una Interface Definition Language (IDL), la piattaforma.NET consente l'integrazione di diversi linguaggi all'interno dello stesso framework a patto che essi rispettino la Microsoft Common Language Specification (MSIL) affinché i loro compilatori producano come output un Intermediate Language (MSIL) che possa essere dato in pasto alla Common Language Runtime (CLR), quasi come fosse la VM di Java.

In pratica ogni linguaggio e componente può essere iniettato all'interno della piattaforma .NET e così compreso e interpretato tramite una traduzione che rispetti la specifica comune del linguaggio e venga riportata all'Intermediate Language. MSIL contiene istruzioni che appaiono simili al codice ASSEMBLY, come lo spostamento di valori fuori e dentro i registri, dispone anche di istruzioni per gestire gli oggetti e chiamare i loro metodi, manipolare gli array e lanciare e catturare eccezioni.

Il Common Language Runtime (CLR)

Avete presente la Java Virtual Machine (JVM) di Java? Il CLR possiamo pensarlo più o meno allo stesso modo, tranne che per un particolare: esso ingloba le regole, definite da .NET come linguaggio intermedio, per diversi linguaggi. Il CLR non fa altro che convertire le chiamate e il codice scritto con sintassi differenti in un linguaggio comune a tutti i linguaggi che sono supportati dal framework. Tutto sarà più chiaro dopo aver appreso cosa sia l'Intermediate Language.

Perché .NET?

Una domanda che sorge subito spontanea dopo aver compreso che cosa ci sia davvero dietro al nome .NET. La CLR stessa potrebbe essere confusa con una virtual machine come quella di JAVA e si potrebbe pensare di studiare semplicemente JAVA, che è anche più vecchio e quindi più consolidato.

Quello che invece deve saltare all'occhio è la volontà di MS di creare qualcosa che non sia un nuovo linguaggio ma solo un insieme di strumenti per far parlare diversi linguaggi e standard con una lingua comune e un insieme di regole da tutti rispettate e condivise. Ogni programmatore, infatti, non vuole cambiare linguaggio ad ogni morte di papa e non si assoggetta a delle regole commerciali quali possono essere quelle di Sun o MS. Lui vuole solo una cosa: un'applicazione perfetta o che almeno si avvicini alla perfezione. Per farlo serve un linguaggio di programmazione e se lui ne conosce uno a menadito non vuole certo impararne uno nuovo, magari più potente e completo del precedente, se non vi è davvero costretto.

La soluzione? Un framework che faccia da traduttore alle chiamate provenienti da linguaggi differenti che abbia un sistema comune di tipi e un linguaggio di traduzione a basso livello. Magari si potrebbe anche desiderare un sottostrato di acesso ai dati comune e una libreria di funzioni che definiamo di base o di sistema. Ecco il perché di .NET.

Microsoft Common Language Specification

La Common Language Specification descrive come devono comportarsi altri produttori di strumenti software affinché questi ultimi possano produrre come output del codice in linguaggio intermedio comprensibile dal CLR.

Microsoft Intermediate Language (MSIL)

Le istruzioni dell'IL appaiono simili a delle istruzioni Assembly, come la manipolazione dello stack e lo spostamento di valori fuori e dentro i registri del processore. Questo linguaggio intermedio dispone inoltre della gestione di oggetti e attributi, della possibilità di invocare metodi, della manipolazione degli array e della cattura delle eccezioni.

Il funzionamento di .NET

Common Type System

Tutti i tipi di dati di .NET sono oggetti che derivano da System.Object.

Versioning e sicurezza

Il problema del versioning è cosa nota agli sviluppatori Microsoft. Ogni applicazione dovrebbe appoggiarsi a determinate DLL, che per definizione dovrebbero essere librerie dinamiche che vengono condivise da più applicazioni e linkate al momento opportuno. Il problema che affligge questo sistema è il fatto che ogni libreria potrebbe avere più versioni e utilizzatori che non sono consci di questo; cosa che puntualmente produce errori o malfunzionamenti. A volte si cerca di installare l'applicazione in modo tale che ogni programma abbia le proprie DLL, magari salvandole in directory private. Ciò comporta un utilizzo improprio delle risorse e una forzatura che va contro il principio stesso alla base della nascita delle DLL. COM stava pian piano modificando tutto ciò definendo un metodo di sviluppo che imponeva al programmatore di non modificare mai un'interfaccia dei metodi, ma aggiungerne unicamente di nuovi. Tutti i programmatori purtroppo vorrebbero essere divini o almeno considerati tali e tutto ciò che producono vogliono vederlo come perfetto, unico e inattaccabile; per questo è stato inutile imporre il tipo di sviluppo citato in precedenza.

Ora .NET separa i componenti dell'applicazione in modo tale che questa carichi sempre i componenti con la quale è stata creata e provata, eliminando questi problemi alla radice.

Assembly

Gli assembly sono il mezzo per creare ed installare componenti .NET. Ogni assembly incorpora molti metadati che specificano il versioning, la sicurezza e molto altro. Nel normale utilizzo .NET ogni assembly può essere composto da più file sorgente. Tutte le informazioni al loro interno servono al CLR per effettuare verifiche sulla sicurezza e per accertarsi che l'applicazione abbia per le mani il componente corretto senza bisogno di definire regole come quelle di COM e lasciando maggiore libertà al programmatore; così non bisogna registrare ogni componente come avveniva con COM.

Grazie anche ai metadati degli assembly i componenti .NET non hanno bisogno di riferimenti nel registry; essi sono autodescrittivi e possono essere installati semplicemente copiandoli in una data directory, un pò come avviene in ambiente UNIX.

Ogni assembly è dotato di uno strong name che definisce in modo univoco l'assembly e ne assicura che non sia stato manipolato. Il framework per mezzo della CLR e del class loader, prima di caricare una classe, verifica l'autenticità del componente e prova quindi se può o meno fidarsi.

Altri metadati importanti contenuti negli assembly sono le policy che definiscono tre livelli di accesso per il componente .NET:

  • l'azienda;
  • la singola macchina;
  • l'utente.

Queste policy vengono impostate dall'amministratore e creano un surrogato a quello che avviene nella sandbox di JAVA.

Ogni chiamata ad un dato metodo viene inoltre verificata tramite i metadati all'interno dell'assembly. Vengono verificati i tipi delle variabili passate, quelli di ritorno e tutto ciò che caratterizza il controllo di sicurezza della chiamata al metodo.