Le cadre d'application .NET avec Visual Basic .NET

Le cadre d'application .NET est une itération unifié de la plate-forme Microsoft pour le développement de logiciels basés sur des composantes. Il fournit des avancées fondamentales dans les services d'exécution pour les logiciels d'application. Il prend également en charge le développement d'applications pouvant être exemptes de dépendances sur le matériel, le système d'exploitation et le compilateur de langage.

CLI (Common Language Infrastructure) et CLR (Common Language Runtime)

Au coeur du cadre d'application .NET se trouve un nouveau mécanisme de chargement et d'exécution de programmes et de gestion de leurs interactions. Ce mécanisme est décrit dans le CLI (Common Language Infrastructure), une spécification pour un environnement d'exécution permettant aux composantes logiciels de :

• passer des données entre eux sans tenir compte du langage de programmation dans lequel chaque composante est écrit.
• exécuter sur différents systèmes d'exploitation et sur différentes plates-formes matérielles sans avoir à recompiler le code source de haut niveau (une compilation de bas niveau se produit toujours automatiquement sur la plate-forme cible).

Bien que la spécification CLI ait été créée par Microsoft, elle a depuis été soumise à l'organisation de normalisation ECMA, en ayant désormais la responsabilité et le contrôle. L'interface de ligne de commande n'est qu'une spécification - elle doit être mise en oeuvre pour être utile. Une mise en oeuvre de l'interface de ligne de commande est appelée CLR (Common Language Runtime). Le CLI spécifie comment le code exécutable est chargé, exécuté et géré. La partie du CLR effectuant les tâches de chargement, d'exécution et de gestion des applications .NET est appelée le système d'exécution virtuelle VES (Virtual Execution System). Le code exécuté par le VES est appelé code géré. La CLI étend considérablement les concepts existant dans le modèle d'objet de composante (COM) de Microsoft. Comme sa caractéristique principale, COM spécifie comment les interfaces d'objet sont disposées en mémoire. Toute composante capable de créer et d'utiliser cette mise en page peut partager des données avec d'autres composantes faisant de même. Le COM était un grand pas en avant lors de son introduction vers 1992, mais il a ses défauts. Par exemple, malgré son nom, le COM n'a en fait aucun concept d'objet - uniquement des interfaces d'objets. Par conséquent, COM ne peut pas prendre en charge le passage de types natifs d'une composante à un autre.

Système de type commun (CTS)

La spécification CLI définit un système de type riche surpassant de loin les capacités de COM. C'est ce qu'on appelle le CTS (Common Type System). Le CTS définit au niveau de l'exécution comment les types sont déclarés et utilisés. Auparavant, les compilateurs de langage contrôlaient la création et l'utilisation des types, y compris leur disposition en mémoire. Cela entraînait des problèmes lorsqu'une composante écrite dans une langage tentait de transmettre des données à une composante écrit dans une autre langage. Quiconque a écrit du code Visual Basic 6 pour appeler des fonctions API de Windows, par exemple, ou ayant essayé de transmettre un tableau JavaScript à une composante écrite en Visual Basic 6 ou C++, est conscient de ce problème. Il appartenait au développeur de convertir les données pour qu'elles soient compréhensibles pour la composante récepteur. Le CTS élimine ce problème en fournissant les fonctionnalités suivantes :

• Les types primitifs (Integer, String,...) sont définis au niveau de l'exécution. Les composantes peuvent facilement passer des instances de types primitifs entre eux car ils sont tous d'accord sur la façon dont ces données sont formatées.
• Les types complexes (structures, classes, énumérations,...) sont construits d'une manière définie au niveau de l'exécution. Les composantes peuvent facilement passer des instances de types complexes entre eux car elles sont tous d'accord sur la façon dont les types complexes sont construits à partir de types primitifs.
• Tous les types portent avec eux des informations de type riches, ce qui signifie qu'une composante à qui un objet est remis peut trouver la définition du type dont l'objet est une instance. Ceci est analogue aux bibliothèques de types dans COM, mais le CTS est différent car les informations de type sont beaucoup plus riches et sont assurées d'être présentes.

Espaces de noms

Les espaces de noms permet de regrouper les types associés. Ils ne sont pas simplement un concept Visual Basic .NET; ils sont également utilisés par le CLR et par d'autres langages ciblant la plateforme .NET. Il est important de garder à l'esprit que pour le CLR, un espace de noms n'est qu'une partie d'un nom de type complet, et rien de plus.

Portions du CLI

La spécification CLI reconnaît que le CLR ne peut pas être mise en oeuvre dans la même mesure sur toutes les plates-formes. Par exemple, la version du CLR mise en oeuvre sur un téléphone portable ne sera pas aussi polyvalente que celle mise en oeuvre sur Windows 2000 ou Windows XP. Pour résoudre ce problème, le CLI définit un ensemble de bibliothèques. Chaque bibliothèque contient un ensemble de classes mettant en oeuvre une certaine partie de la fonctionnalité de l'interface de ligne de commande. En outre, le CLI définit des profils. Un profil est un ensemble de bibliothèques devant être mise en oeuvres sur une plateforme donnée. Les bibliothèques définies par la CLI sont :

Les profils définis par la CLI sont :

Des profils supplémentaires seront définis dans les futures versions de la spécification CLI. Toute mise en oeuvre donnée de la CLI est libre de mettre en oeuvre plus que les fonctionnalités spécifiées par ces profils minimaux. Par exemple, une mise en oeuvre donnée peut prendre en charge le profil compact mais également la bibliothèque à virgule flottante. Le cadre d'application .NET sur Windows 2000 prend en charge toutes les bibliothèques CLI, ainsi que des bibliothèques supplémentaires non définies par le CLI.

Notez que l'interface de ligne de commande n'inclut pas les bibliothèques de classes majeures telles que Windows Forms, ASP.NET et ADO.NET. Il s'agit de bibliothèques de classes spécifiques à Microsoft pour le développement d'applications sur les plates-formes Windows. Les applications dépendant de ces bibliothèques ne seront pas portables vers d'autres mise en oeuvres de l'interface de ligne de commande à moins que Microsoft rend ces bibliothèques de classes disponibles sur ces autres mises en oeuvres.

Modules et Assembly

Un module est un fichier .exe ou .dll. Un Assembly est un ensemble d'un ou de plusieurs modules formant ensemble une application. Si l'application est entièrement contenue dans un fichier .exe, c'est un Assembly à un seul module. Si le .exe est toujours déployé avec deux fichiers .dll et que l'on pense que les trois fichiers constituent une unité inséparable, alors les trois modules forment ensemble un Assembly, mais aucun d'eux ne le fait tout seul. Si le produit est une bibliothèque de classes existant dans un fichier .dll, ce fichier .dll unique est un Assembly. Pour le dire dans les termes de Microsoft, l'Assembly est l'unité de déploiement dans .NET.

Un Assembly est plus qu'une manière abstraite de penser à des ensembles de modules. Lorsqu'un Assembly est déployé, un (et un seul) des modules de l'Assembly doit contenir le manifeste d'Assembly, contenant des informations sur l'Assembly dans son ensemble, y compris la liste des modules contenus dans l'Assembly, la version de l'Assembly, sa culture,... Le compilateur de ligne de commande et le compilateur Visual Studio .NET créent par défaut des Assembly à module unique.

Les limites de l'Assembly affectent la résolution du type. Lorsqu'un fichier source est compilé, le compilateur doit résoudre les noms de type utilisés dans le fichier en définitions de types. Pour les types définis dans le même projet source, le compilateur obtient les définitions du code qu'il compile. Pour les types définis ailleurs, le compilateur doit savoir où trouver les définitions. Cela se fait en référençant les Assembly contenant les définitions de type compilées. Lorsque le compilateur de ligne de commande est utilisé, le paramètre /reference identifie les Assembly contenant les types utilisés dans le projet en cours de compilation. Un Assembly porte le même nom que le module contenant le manifeste d'Assembly, à l'exception de l'extension de fichier. Dans certains cas, cependant, un Assembly est spécifié en donnant le nom complet du module contenant le manifeste d'Assembly. Par exemple, pour compiler une application utilisant la classe System.Drawing.Point, vous pouvez utiliser la ligne de commande suivante :

La documentation du compilateur de ligne de commande indique que le paramètre du commutateur de référence est un Assembly. Ce n'est pas tout à fait exact. Le paramètre est le nom du module contenant le manifeste d'Assembly pour un Assembly. Si plusieurs Assembly doivent être référencés, vous pouvez tous les lister dans le même paramètre /reference, séparés par des virgules, comme ceci :

Le compilateur de ligne de commande Visual Basic .NET référence automatiquement deux Aassembly : mscorlib.dll, contenant la plupart des types trouvés dans l'espace de noms System; et Microsoft.VisualBasic.dll, contenant les types trouvés dans l'espace d'entreposage Microsoft.VisualBasic.