Editions ENI Livres | Vidéos | e-Formations
Framework .NET et .NET Core
Introduction à .NET
Nous vous disons depuis le début de cet ouvrage que PowerShell tire sa puissance du Framework .NET. L’heure est enfin arrivée, il est temps d’entrer dans davantage de détails.
Pour faire simple, lorsque Jeffrey Snover a conçu PowerShell, le Framework .NET venait de naître et sa popularité se faisait grandissante dans la communauté des développeurs. En effet, celui-ci offre un très grand nombre de fonctions prêtes à l’emploi qui permettent d’accroître significativement la productivité des développeurs. Ces fonctions prêtes à l’emploi - appelées « classes » dans le jargon - évitent au développeur d’avoir à réinventer la roue, ainsi ces derniers peuvent se focaliser davantage sur le code utile de leur programme.
Snover a donc succombé aux sirènes du Framework .NET, pour notre plus grand bien, et nous n’allons pas nous en plaindre, bien au contraire !
Ainsi, lorsque nous utilisons PowerShell, nous utilisons indirectement le Framework .NET. Par exemple lorsque nous déclarons une variable, cette dernière utilise un type du Framework .NET et non pas un type spécifique à PowerShell (bien qu’il puisse en exister quelques-uns).
Parfois, lorsque PowerShell ne possède pas la commande que nous voulons...
Le framework .NET
Connu de nombreux développeurs, le framework .NET est un composant Windows apparu en version finale pour la première fois en 2002. Indispensable à l’installation de PowerShell, le framework est désormais installé nativement sur les systèmes Windows. Destiné à faciliter le développement des applications informatiques, le framework fournit une immense bibliothèque de classes, sur laquelle s’appuient certains langages comme le C#, le VB.NET, le J#, et bien évidemment PowerShell.
Architecture logicielle
Composition du Framework .NET
Sans rentrer dans des détails trop techniques qui ne seraient pas vraiment utiles pour la compréhension, retenez simplement que le Framework .NET est composé de deux éléments principaux :
-
Le CLR (Common Language Runtime), environnement d’exécution compatible avec tout langage de programmation respectant le CLS (Common Language Specification). Le CLR est l’équivalent de la machine virtuelle Java ; c’est lui qui interprète le bytecode issu de la compilation d’un programme .NET.
-
Les bibliothèques de classes contiennent tous les types que l’on peut trouver dans le Framework .NET. Chaque classe étant répertoriée dans un espace de noms.
Versions successives du Framework .NET
Au fil des années, le Framework .NET s’est...
.NET Core
Contrairement au Framework .NET qui, lui, ne fonctionne que sur la plateforme Windows, .NET Core est né multiplateforme.
.NET Core est la dernière mouture du Framework .NET, sauf que celle-ci est open source. Oui, vous avez bien lu, .NET Core est la réécriture complète du Framework .NET mais en version open source. Vous imaginez la quantité astronomique de travail à fournir pour passer d’une version à l’autre ? C’est absolument colossal, mais nous n’avons aucun doute que l’objectif sera atteint dans quelques années. De plus, du fait que .NET Core soit open source, cela signifie que tout le monde peut contribuer à son développement, ce qui ne peut que booster son portage ainsi que doper ses fonctionnalités.
Ce portage a du bon car il a forcé Microsoft à dépoussiérer son code et donc à l’optimiser. De plus, du fait que .NET Core reparte d’une page blanche, celui-ci bénéficie de plus de quinze années d’expérience acquise par Microsoft durant le développement de son grand frère. C’est probablement pour cela que .NET Core est beaucoup plus léger et nettement plus véloce que son aîné.
La version stable actuelle de .NET Core à l’heure où nous écrivons ces lignes est la version 2.1.4.
Qu’est-ce...
PowerShell Core vs Windows PowerShell, à quel saint se vouer ?
Que les choses soient claires, Microsoft met toute son énergie dans .NET Core ainsi que dans PowerShell Core. Bien que Windows PowerShell et le Framework .NET restent bien évidemment supportés, qu’on se le dise, ces deux composants majeurs de l’écosystème Microsoft n’évolueront plus. Il n’y aura plus de nouvelles fonctionnalités, seulement des correctifs de sécurité. Oui, cela est un choc, mais nous allons devoir nous y faire !
La version 5.1 sera donc la dernière version de Windows PowerShell. L’avenir est donc à chercher du côté du monde plus ouvert avec PowerShell Core (version 6). La transition risque d’être douloureuse car il va falloir tester tous nos scripts et il y a fort à parier que nous devrons en adapter plus d’un, car c’est un gros changement auquel nous avons affaire. Cela dit, nous avons encore le temps, car PowerShell Core vient tout juste de sortir et Windows PowerShell va être supporté encore de nombreuses années.
Quelle version de PowerShell choisir ?
Nous n’avons pas beaucoup d’autre choix que d’accompagner le changement. C’est la loi de l’évolution, s’adapter ou mourir ! Heureusement ce changement n’est pas aussi dramatique qu’il en a l’air, mais...
Utiliser des objets .NET avec PowerShell
À partir de maintenant, et jusqu’à la fin du chapitre, nous ne ferons plus la distinction entre le Framework .NET et .NET Core, car tout ce que nous allons voir s’applique aux deux frameworks.
Dans cette partie, nous allons vous expliquer ce qu’est le Framework .NET, ce qu’il contient, comment rechercher des classes susceptibles de nous intéresser, comment créer des objets, et comment lister leurs membres.
Nous parlerons indifféremment de classe .NET ou de type .NET, car ces deux termes désignent la même chose.
Avant toute chose, il faut savoir que dans l’environnement .NET, tout a un type. Jusqu’à maintenant, sans vraiment porter attention, nous avons manipulé de nombreux objets qui possédaient chacun un type bien particulier défini dans la bibliothèque du Framework. Prenons par exemple le cas de l’objet retourné par la commande Get-Date.
PS > $Date = Get-Date
PS > $Date.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True DateTime System.ValueType
En appliquant la méthode GetType à l’objet représenté par $Date, nous pouvons observer que le type utilisé est DateTime et que son espace de noms est System. Soit le nom complet : System.DateTime.
On appelle espace de noms (ou namespace en anglais) ce qui précède le nom d’une ou plusieurs classes .NET ou WMI. Ils sont utilisés dans le but d’organiser les objets et ainsi éviter de confondre des classes qui pourraient éventuellement porter le même nom.
Pour obtenir plus d’informations, sachez que tous les types (qu’il s’agisse de classes, de structures, d’énumérations, de délégués ou d’interfaces) définis dans la bibliothèque de classe Framework, sont détaillés sur le site de Microsoft MSDN.
Description d’une classe du Framework .NET sur MSDN
À l’instar des types rencontrés jusque-là...
Tirer parti de la puissance de .NET
L’utilisation de .NET donne à PowerShell une ouverture sur des milliers de classes prêtes à l’emploi. Par conséquent, manipuler les objets .NET, c’est permettre une plus grande flexibilité mais également donner d’autres perspectives à nos scripts.
Afin d’illustrer ces propos, nous allons dans cette partie, expliquer étape par étape comment exploiter quelques classes à travers différentes situations, comme :
-
Le Wake-on-LAN (réveil en ligne) d’un ordinateur.
-
La compression de fichiers.
-
L’affichage de bulles d’informations contextuelles.
1. Wake-on-LAN
Le Wake-on-LAN (WOL) est un procédé qui permet d’allumer un poste éteint via l’envoi sur le réseau Ethernet, d’une suite d’octets un peu particulière appelée « paquet magique ».
Aujourd’hui, toutes les cartes mères le supportent, néanmoins il se peut que le Wake-on-LAN soit désactivé dans le BIOS de votre machine.
Le paquet magique permettant de déclencher le WOL est une suite de 102 octets dont les 6 premiers prennent la valeur hexadécimale FF, et les 96 suivants sont 16 fois la répétition de l’adresse MAC (Media Access Control) de la carte réseau de l’ordinateur distant. Pour créer ce paquet, nous utiliserons le tableau d’octets suivant :
PS > [byte[]]$Adresse_Mac = 0x00, 0x11, 0x43, 0x0E, 0x97, 0x4F
PS > [byte[]]$paquet = 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
PS > $paquet += $Adresse_Mac * 16
Une fois le paquet constitué, il faut maintenant l’envoyer via le réseau. Et pour ce faire, nous allons utiliser la classe UdpClient (présente dans l’espace de noms System.Net.Sockets) qui fournit les services réseau nécessaires à l’envoi de datagrammes UDP (User Datagram Protocol) :
PS > $UdpClient = New-Object System.Net.Sockets.UdpClient
C’est grâce à cette classe et plus particulièrement à la méthode Connect que l’on va pouvoir établir une connexion avec un hôte distant....
