Cours accès aux données VB Net
...
.NET : une vision du futur ?
Un framework est mot à mot un « cadre de travail ». Lorsqu’on parle du framework .NET, il s’agit donc de l’ensemble des outils et spécifications créant ipso facto un tel cadre dans lequel s’inscriront à la fois l’analyse et la réalisation d’une application. On parle aussi de plate-forme .NET comme on parlait de la plate-forme Windows, voire de la plate-forme Intel. À y regarder de plus près, .NET apparaît comme une version enfin achevée et objet des API Win32. Mais .NET est plus que cela, c’est aussi une vision de l’informatique de demain.
En effet, .NET est une réorganisation en profondeur dessinant l’informatique du futur et s’attaquant aussi bien aux langages qu’aux bibliothèques produites et aux rapports qu’elles entretiennent avec les plates-formes techniques sous-jacentes et dont le champ d’application s’étend de l’informatique domestique à la télévision interactive en passant par les PDA et l’informatique industrielle.
En bref, il s’agit aujourd’hui pour l’informatique d’être, selon le terme repris par Microsoft, « agile ». Agile donc souple, simplifiée, passe-partout et surtout intégrée. Intégrée à quoi ? À tout ! Un PDA doit pouvoir servir à passer une commande via une interface de type Web en surfant sur un site dont la base de données est utilisée simultanément par la gestion commerciale et comptable de la société et vous renvoyant une confirmation de commande sur votre téléviseur… À moins que ce ne soit votre frigidaire qui aura passé commande tout seul des denrées indispensables dont le stock sera descendu sous le minimum que vous aurez fixé et les produits livrés par un coursier averti sur son portable par un SMS transmis par l’ordinateur du supermarché local qui aura reçu votre commande et l’aura préparée…
Science-fiction ? Vision « microsoftienne » mercantile d’un avenir radieux pour ses actionnaires où même un grille-pain devra disposer d’une licence Windows en règle ? Vision d’horreur d’un futur orwellien ?
Tout ceci n’est pas exclu… les consommateurs que nous sommes étant très friands de technologie et s’offrant si docilement aux modes et aux lavages de cerveaux staracadémiesques dont on nous abreuve pour mieux nous diriger... La fascination en une science toute puissante, secrètement vécue comme un moyen de réparer nos errances désastreuses pour notre propre écosystème n’y ait pas pour rien non plus… Et puis l’humain modifie lui-même son futur, par son imagination débordante. Les communicateurs de Star Trek avec lesquels le capitaine Kirk pouvait, depuis une planète exotique, dialoguer avec l’Enterprise étaient-ils l’invention d’un scénariste visionnaire préfigurant nos téléphones portables modernes ou bien est-ce l’idée du scénariste qui s’est lentement insinuée dans la société et a suscité à quelques ingénieurs le concept de nos portables ? Il y a fort à parier qu’il s’agisse en réalité d’une interaction à double sens et que nos fantasmes technologiques, qu’ils soient l’œuvre de scénaristes de science- fiction ou de directeurs marketing, influencent directement ce que l’industrie créera en réponse à la demande du public… Le peuple victime de ses propres rêves ? Qui peut dire exactement la part inconsciente du plaisir de tenir un portable de 60 grammes à la main que l’on doit aux communicateurs de Star Trek ? Qui sait, demain, la part qu’aura jouée la vision de Microsoft dans ce que nous considérerons alors comme indispensable ? L’idée de Microsoft est lancée et elle va inévitablement changer les choses par le simple fait qu’elle a été émise. Et que l’intention première soit une vision géniale du futur ou un simple pari commercial n’y change rien, l’idée va se propager jusqu’à modifier notre façon de percevoir l’informatique. Le marketing consiste à susciter l’envie chez le client et, dans ce domaine, la firme de Redmond a toujours été considérée comme imbattable, même par ses détracteurs. Ne boudons pas notre plaisir, ne gâchons pas de possibles évolutions bénéfiques par un passéisme illusoirement protecteur, mais restons vigilants…
L’architecture .NET
À l’heure où cet article est écrit, le framework est désormais disponible en version 2.0. La version 1.1 couvrait de très nombreux domaines, des applications de gestion classiques aux services Web en passant par les sites services Windows et les applications console ce qui en faisait une base solide pour réellement développer sous .NET. Elle restera certainement encore utilisée quelques temps mais les améliorations de la version 2.0 feront certainement pencher assez vite la balance en la faveur de cette dernière.
Le point fort de .NET est d’intégrer des technologies existantes dans un tout cohérent. Par exemple, tout ce qui concerne les communications de données reste basé sur SOAP, XML et HTTP. En aucun cas Microsoft n’a cherché à bouleverser les acquis, ce qui est une nouveauté.
La seule différence technique majeure est l’adoption d’un système d’exécution virtuel (VES) et qui se trouve désormais au cœur de toute la structure .NET et sur laquelle tout repose.
L’ensemble .NET peut être ainsi divisé en :
On peut aussi préférer un autre angle de vue et découper .NET en quatre pôles :
Figure 2.1
Le framework .NET
2 Runtime du langage commun (machine virtuelle)
c’est-à-dire la machine virtuelle de .NET, celle qui exécute le code IL appelé aussi CIL (Common Intermediate Language3), le pseudo- code du CLR.
Machine virtuelle ou non ?
Si l’on regarde de plus près le fonctionnement de .NET, il s’avère que le terme de « machine virtuelle » tel qu’on l’entend par exemple sous Java, c'est-à-dire un interpréteur de pseudo-code, est mal choisi , Microsoft semble d’ailleurs refuser ce terme. En effet, le pseudo-code .NET n’est jamais interprété comme cela se fait sous Java mais compilé avant d’être exécuté. Bien que la machine virtuelle .NET prenne en compte des tâches similaires à celles de Java (gestion de codes intermédiaires, gestion mémoire, ramasse-miettes et sécurité), il existe une nuance importante. Le terme « machine virtuelle » employé à propos du CLR de .NET doit donc être pris uniquement comme une comparaison simplificatrice.
Au-dessus du CLR se trouve l’ensemble des librairies de classes du framework, couche sur laquelle repose la gestion des données. Au sommet de cette construction, se trouvent deux blocs, celui des Windows Forms (WinForms), ensemble de classes permettant la conception d’IHM4 Windows et celui appelé ASP.NET. Ce dernier n’a pas grand-chose à voir techniquement avec ce qu’on désigne par ASP sous Win32. ASP.NET est un ensemble de classes permettant à la fois la conception de sites dynamiques, la création d’IHM pour le Web, les WebForms et la conception de services Web.
Les bases de .NET
L’ensemble .NET repose sur le CLR, le runtime en charge de l’exécution du code CIL.
Le CLR
3 Langage Intermédiaire Commun
4 IHM : Interface Homme-Machine
Les métadonnées contenues dans les fichiers exécutables .NET informent le CLR sur les éléments suivants :
Grâce à l’ensemble de ces informations et à ses propres caractéristiques, le CLR est en mesure d’offrir aux applications managées6 une meilleure gestion des exceptions, la possibilité d’utiliser des composants écrits dans d’autres langages, une meilleure gestion de la sécurité des applications et une meilleure gestion des ressources, mémoire comprise. La figure 2.2 montre comment les IDE et les langages se positionnent par rapport au framework et au CLR.
Figure 2.2
Le CLR, le Framework et les IDE
5 le terme « culture » sous .NET désigne l’ensemble des informations de localisation de l’utilisateur (langue et paramètres régionaux principalement).
6 « managé » est un anglicisme venant de « managed » voulant dire « géré ». Le
« code managé » est celui qui est exécuté sous contrôle du CLR .NET. Certains préfèrent dire « code géré » plus français mais un peu vague.
La BCL ou FCL
La BCL et CLR forment à eux deux l’essentiel du framework et offre aux applications managées un support particulièrement performant pour les exceptions, les entrées/sorties, le mécanisme de réflexion (équivalent de l’introspection Java et des RTTI Delphi), la gestion de la sécurité, l’accès aux données, la gestion des IHM dites « riches » pour Windows et le Web, et bien d’autres services.
Les espaces de nom
Sous .NET toute classe est repérée dans un espace de nom7 (namespace). Ce procédé simple et puissant permet d’éviter les conflits de noms entre différentes bibliothèques.
La gestion de ces espaces est particulièrement intuitive puisque chaque niveau de sous-espace est séparé des niveaux supérieurs par un simple point dans le nom. Ainsi, on trouve le framework de nombreux espaces de noms, chacun étant spécialisé dans un type de service. Ce procédé, en dehors de prévenir les conflits de noms, apporte une hiérarchisation des bibliothèques. Un bon exemple est le framework lui-même et ces milliers de classes hiérarchisées grâce à ce procédé.
CIL, CLI, JITer et code managé
Le CIL est le pseudo-code généré par les compilateurs des langages compatibles .NET. Ces langages sont d’ores et déjà nombreux et à côté de ceux produits par Microsoft tels que C# (créé par le concepteur du langage de Delphi Anders Hejlsberg), J# (un Java pour .NET), VB.NET (version .NET de Visual Basic) et Managed
7 On trouve aussi l’expression « espace de nommage » pour désigner ce procédé. Ce néologisme utilisé dans notre précédent ouvrage ne nous semblant pas élégant nous lui préfèreront ici « espace de nom ».
C++ (une version spéciale de C++ pour .NET), nous trouvons Delphi .NET et son Pascal Objet mais aussi : COBOL.NET, Fortran.NET, Ruby.NET, P# (un Prolog pour .NET), S# (Smalltalk pour .NET), PHP.NET…
CIL vs MSIL ou l’universalité de .NET
Le CIL, le langage commun intermédiaire, est aussi appelé MSIL pour Microsoft Intermediate Language lorsqu’il est adapté à l’implémentation spécifique Microsoft du framework .NET. En effet, .NET peut exister pour d’autres platesformes que Windows et être mis en œuvre par d’autres éditeurs. Il existe, par exemple, un framework .NET en cours de conception sous le nom de MONO. C’est un projet Open Source mené sous l’égide de Novell afin de créer une implémentation gratuite du framework. Les premières versions sont déjà distribuées pour Windows, mais également pour Linux avec Red Hat, SuSE, Debian, Mandrake…
L’infrastructure sur laquelle le CLR se repose s’appelle CLI, pour Common Language Infrastructure. CLI dispose d’une spécification publique et ouverte qui assure dès maintenant la propagation rapide de .NET (autant dans la diversité des langages existants et à venir que dans les diverses implémentations dont MONO).
Le CLI est ISO
Confirmant l’ouverture de .NET, il est important de noter que depuis avril 2003, un sous-ensemble du CLI a été porté au rang de standard international par l’ISO/IEC (International Organization for Standardization/International Electrotechnical Committee).
Lorsque le CLR exécute un programme compilé en CIL, il commence par vérifier si ce fichier a déjà été compilé en langage machine. Si tel est le cas, il ouvre l’image binaire et l’exécute ; sinon, il invoque le JITer (Just In Time Enhanced Runtime) qui a la charge de traduire le CIL en un véritable programme en langage machine pour la plate-forme hardware cible.
.NET sur Win32 et Java est qu’il a été conçu ultérieurement et qu’il a su tiré leçon des erreurs de conceptions de ces derniers. Il répond à la pléthore des API non unifiées de Win32 par un framework cohérent, il répond au mélange interprétation / compilation de Java par l’intégration d’emblée d’un système de compilation efficace. Et à défaut de promettre l’universalité trompeuse, car illusoire, de la portabilité de Java (de surcroît finalement inutile dans un monde dominé par la plate-forme PC), il offre d’emblée la pluralité des langages prenant ici une avance confortable sur ses compétiteurs limités à leur propre syntaxe.
Un code compilé et exécuté par le CLR est appelé un « code managé » (managed code) ou « code géré » si on préfère éviter le néologisme.
Figure 2.3
Du code source au binaire exécuté
La figure 2.3 présente la transformation d’un code source écrit en différents langages .NET (C#, VB.NET et Delphi .NET), d’abord en code CIL par le biais des compilateurs respectifs des langages considérés ici, puis en binaire par le JITer invoqué par le CLR.
Le célèbre « Hello World ! » passe ainsi par trois phases (code source, code CIL, code binaire) avant de pouvoir être exécuté sur une machine cible. Le code exécutable Delphi produit un fichier qui ne peut être exécuté que par .NET mais dont la reconnaissance est automatique sous Windows (l’installation du runtime ou du SDK .NET ayant ajouté un filtrage donnant la main au CLR lorsque l’exécutable est un fichier exécutable du framework).
En attendant de tels processeurs dédiés CIL, le JITer effectue la compilation du langage intermédiaire en binaire. Il le fait à la volée, d’où son nom (Just In Time…) et cela classe par classe, selon trois modes :
Sous Windows c’est le premier mode qui est exploité par défaut alors que le troisième est préféré sur les équipements à faible mémoire, comme les assistants personnels. La seconde méthode permet d’accélérer une application dont la vitesse d’exécution est cruciale. On force alors la compilation totale de l’exécutable ainsi que son installation dans le cache (GAC, Global Assembly Cache ou Cache global des assemblages).
La Shadow Copy
Le code d’un assemblage .NET, EXE ou DLL peut être mis en cache en vue de son exécution, simplifiant les opérations de mise à jour. C’est la copie compilée binaire qui est alors utilisée et non l’original. Cette technique est appelée Shadow Copy que l’on traduirait en français par « copie miroir ». Cela permet de mettre à jour l’assemblage, même en cours d’exécution, ce qui simplifie les choses par rapport aux DLL et EXE Win32 qui ne peuvent pas être écrasés en cours d’exécution. La Shadow Copy se met en route volontairement par programmation (caractéristique de l’AppDomain) comme le fait ASP.NET pour faciliter la mise à jour des modules sur un site Web.
Les fichiers PE - Portable Executable
Sous Windows les fichiers exécutables (EXE et DLL) doivent se conformer au format PE (Portable Executable - exécutable portable). Ce format dérive de COFF (Common Object File Format) qui est une norme publique équivalente au format ELF de Linux.
L’en-tête PE proprement dit suit l’en-tête DOS, tout cela précédant une série de sections (.text, .data, .rdata, .rsrc, ainsi que d’autres sections optionnelles).
.NET créé lui aussi des EXE mais ils sont de nature très différentes. Si les fichiers PE de DOS jusqu’aux versions les plus récentes de Win32 ne peuvent contenir que du code compilé en langage machine et des données, les exécutables .NET ajoutent des métadonnées et du code IL, indispensables au CLR. Les métadonnées permettent au CLR de savoir comment charger les classes et le code IL lui permet d’effectuer la compilation des différentes classes via le JITer. Pour satisfaire les besoins du CLR, Microsoft a été obligé d’étendre le format PE sans le remettre en cause. Pour ce faire, deux sections ont été ajoutées : un en-tête CLR et des données CLR. Ce nouveau format PE est illustré figure 2.4.
Figure 2.4
Le format de fichier PE de .NET
Les métadonnées et la réflexion
La structure d’un exécutable .NET lui permet d’exposer de nombreuses informations techniques sur l’application, notamment son code IL et ses métadonnées.
Ces dernières peuvent être visualisées facilement à l’aide de l’utilitaire ILDASM fourni avec le SDK du framework. Cet outil peut même désassembler proprement le code IL qui pourra être recompilé à l’aide de ILASM, le compilateur de CIL, comme un assembleur permet de compiler du code symbolique en code machine sous Win32 (ou d’autres plates-formes).
Figure 2.5
Les métadonnées vue par ILDASM
La figure 2.5 présente les informations exposées par le programme console OD.DotNet.Delphi.Delegates.exe compilé avec Delphi .NET. On peut voir les assemblages référencés ainsi que les méthodes publiées. On peut inspecter les unités, puis les classes et les méthodes contenues dans chaque classe. À partir de cette vue, il est aussi possible d’obtenir le désassemblage de l’application.
.method public static void FonctionDeDelegation(int32 i) cil managed
{
// Code size 28 (0x1c)
.maxstack 4
.locals init ([0] object[] V_0)
IL_0000: ldstr bytearray
(4C 00 65 00 20 00 70 00 61 00 72 00 61 00 6D 00
// L.e. .p.a.r.a.m.
E8 00 74 00 72 00 65 00 20 00 76 00 61 00 75 00
// ..t.r.e. .v.a.u.
74 00 20 00 7B 00 30 00 7D 00 )
// t. .{.0.}.
IL_0005: ldc.i4.1
IL_0006: newarr [mscorlib]System.Object IL_000b: stloc.0
IL_000c: ldloc.0 IL_000d: ldc.i4.0 IL_000e: ldarg.0
IL_000f: box [mscorlib]System.Int32 IL_0014: stelem.ref
IL_0015: ldloc.0
IL_0016: call void [mscorlib]System.Console::WriteLine(
string, object[])
IL_001b: ret
} // end of method Delegates::FonctionDeDelegation
On peut voir que ce code est finalement très proche du code source Delphi même s’il est découpé en étapes élémentaires plus nombreuses. Il est en tout cas très lisible et facilement compréhensible, bien plus que le désassemblage d’un exécutable binaire Win32.
Le code Delphi correspond au désassemblage ci-dessus est :
procedure FonctionDeDelegation(i : integer); begin
Console.WriteLine('Le paramètre vaut {0}',[i]); end;
L’ensemble des métadonnées et du code IL permet l’inspection d’un exécutable .NET depuis l’extérieur, c'est-à-dire en inspectant le fichier disque.
Il est possible d’avoir accès aux mêmes informations depuis l’intérieur d’une application en utilisant le système dit de réflexion qui correspond au système des RTTI (Run Time Type Information) de Delphi. Le système de réflexion joue un rôle essentiel dans l’interopérabilité des langages au sein de .NET.
.NET de plusieurs façons. En effet, le framework met à disposition un système de signature qui interdit la modification de l’exécutable ; par ailleurs, des outils appelés « obfuscateurs » rendent le code CIL illisible. Nous aborderons ces aspects ultérieurement.
