Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Secrets de création d'une application WPF dans Windows PowerShell
Doug Finke
Télécharger l'exemple de code
Windows PowerShell offre une nouvelle classe d'automatisation des tâches. En fait, il amplifie d'anciennes technologies plus qu'il ne les remplace. L'utilisation de Windows PowerShell (que nous nommerons simplement PowerShell à partir de maintenant pour simplifier les choses) ne signifie pas que vous devez refaire votre application pour profiter de cette technologie. Vous pouvez plutôt utiliser PowerShell pour intégrer et étendre de façon transparente ce que vous avez déjà.
PowerShell est une technologie d'automatisation présentée comme une interface de ligne de commande (CLI), un langage de script et une API.
Dans cet article, j'examinerai les techniques clés de PowerShell et je créerai un calculateur de valeur actuelle (bit.ly/7oEij1) avec une interface utilisateur graphique Windows Presentation Foundation (WPF) (voir la figure 1).
Figure 1 Le calculateur de valeur actuelle PowerShell
Je présenterai plusieurs éléments clés de PowerShell : le WPF PowerShell Kit (WPK), le pipeline d'objets, les fonctions, les PSObjects avec propriétés, l'intégration transparente avec Microsoft .NET Framework, les modules, etc.
PowerShell est construit sur .NET Framework, ce qui vous permet d'accéder aisément à l'infrastructure comme vous le feriez avec tout autre langage .NET. En outre, vous avez accès au reste du système d'exploitation Windows et à ses composants tels que les services, les processus et Windows Management Instrumentation (WMI), et vous disposez d'un accès aux serveurs distants (pour lesquels PowerShell version 2 et Windows Remote Management sont également activés).
Tout cela est effectué avec le nouveau langage de script exposé par PowerShell. Vous avez simplement besoin de Notepad et de quelques cmdlets (une commande légère utilisée dans l'environnement PowerShell). La bonne nouvelle, c'est que vous êtes prêt à commencer. Les cmdlets sont créées dans PowerShell et Notepad est fourni avec Windows. Les trois cmdlets principales sont les suivantes : Get-Help, qui affiche des informations sur les commandes et les concepts de PowerShell ; Get-Command, qui obtient des informations de base sur les cmdlets et d'autres éléments des commandes PowerShell ; et Get-Member, qui obtient les « membres » (propriétés et méthodes) des objets.
Tout est question de découverte et ces cmdlets vous permettent de parcourir la nouvelle plateforme d'automatisation des tâches.
Commençons
Question : Combien de lignes de code sont-elles nécessaires pour créer une application WPF dont le nom indique « Hello World » ?
Réponse : Deux si vous utilisez PowerShell et WPK, comme illustré à la figure 2.
Figure 2 Application WPF PowerShell composée de deux lignes
Il s'agit d'une application WPF complète écrite en deux lignes de PowerShell. Ligne 1, Import-Module WPK, importe le package WPK qui contient un ensemble de cmdlets PowerShell encapsulant WPF. Il est intéressant de noter que vous n'avez pas besoin de Visual Studio, de XAML ni de C# pour que cela fonctionne. Vous devez cependant installer WPK (voir la section suivante).
PowerShell version 2 est disponible dès le départ dans Windows 7 et Windows Server 2008 R2 (et il peut être téléchargé pour des systèmes Windows plus anciens). Parallèlement à la publication des systèmes d'exploitation serveur et clients, le pack PowerShell était lancé (sous forme de téléchargement distinct), avec le WPK. C'est une reconnaissance du populaire outil de script Unix Tcl/Tk.
Je commencerai par créer l'application en partant d'un ensemble simple de variables PowerShell et en allant jusqu'à une application WPF interactive. J'utiliserai l'environnement d'écriture de scripts intégré de Windows PowerShell (ISE).
Vous souhaitez suivre les étapes avec moi ?
Si vous disposez de Windows 7, vous êtes presque prêt (n'oubliez pas que PowerShell est intégré).
Dans le cas contraire, téléchargez et installez PowerShell pour les systèmes d'exploitation plus anciens. Veillez à bien choisir le téléchargement du système d'exploitation approprié. Consultez le package Windows Management Framework Core (bit.ly/9POYjq).
Quelle que soit la version de votre système d'exploitation, vous devez télécharger et installer WPK (bit.ly/dFVpfL). Il fait partie du Kit de ressources Windows 7 et contient neuf autres modules PowerShell, dont le pack ISE à utiliser dans PowerShell ISE. L'environnement ISE est disponible dès le départ avec PowerShell version 2. Le pack ISE est également une grande ressource d'apprentissage qui illustre les méthodes de personnalisation de l'ISE à plusieurs niveaux.
Une fois que vous avez démarré PowerShell, exécutez la cmdlet suivante : Set-ExecutionPolicy RemoteSigned. Initialement, PowerShell est défini de façon à ne pas exécuter de scripts ; il s'agit d'une fonction de sécurité que les utilisateurs de PowerShell doivent remplacer. Pour que la cmdlet Set-ExecutionPolicy fonctionne, vous devez disposer des droits d'administrateur et exécuter explicitement PowerShell en tant qu'administrateur en cliquant avec le bouton droit de la souris sur le fichier programme PowerShell et en sélectionnant « Exécuter en tant qu'administrateur ».
Téléchargez et décompressez les scripts du téléchargement de code accompagnant cet article. La façon la plus simple d'exécuter l'application est de procéder dans l'environnement ISE. Sous Windows 7, vous pouvez cliquer sur Démarrer et taper ISE. (Remarque : vous ne pouvez pas exécuter de scripts PowerShell, qui ont l'extension de fichier .ps1, en double-cliquant dessus. La façon la plus simple d'exécuter les exemples de script est de lancer l'ISE et d'utiliser Fichier | Ouvrir pour ouvrir le fichier de script.)
Les bases de PowerShell
Je vais créer un calculateur de valeur actuelle. Il s'agit d'une formule simple illustrée à la figure 3.
Figure 3 Calculateur de valeur actuelle
Dans PowerShell, les variables commencent par le symbole $. À la ligne 7, j'utilise directement .NET Framework et j'appelle la méthode statique Pow sur l'espace de noms System.Math. La méthode Pow retourne un nombre spécifié élevé à la puissance spécifiée. La syntaxe nécessaire à l'appel d'une méthode .NET statique se compose de crochets autour de la classe suivis de deux fois deux-points, puis du nom de la méthode : [System.Math]::Pow(2,3). Si vous exécutez cela dans l'ISE, appuyez sur F5 (ou cliquez sur le bouton Exécuter) pour consulter les résultats dans le volet de sortie. Vous pouvez également copier et coller ce code dans la console de ligne de commande PowerShell, qui exécutera et imprimera le résultat.
C'est un excellent début, mais qui n'est pas facilement réutilisable. Je pourrais continuer à taper de nouvelles valeurs et à exécuter ce script, mais je souhaite l'appeler à partir d'autres scripts. J'ajouterai le mot clé fonction et transformerai les variables en paramètres afin de pouvoir varier la sortie et de rendre le script interactif (voir la ligne 2 à la figure 4).
Figure 4 Création d'une fonction PowerShell
Ajout du mot clé Function
Je vais nommer la fonction Get-PresentValue. Il est recommandé de suivre la convention verbe-nom de PowerShell lorsque vous nommez les fonctions, il s'agit d'un concept fondamental de l'utilisation et du développement pour PowerShell. Il comporte des verbes prédéfinis tels que Get, Invoke, New et Remove (tapez Get-Verb pour consulter la liste complète). Essayez de taper Get-Command. Vous obtiendrez toutes les cmdlets (et plus) définies dans votre session PowerShell, et la liste et longue.
Il est aussi simple de créer une fonction que de taper function Get-PresentValue {}. Je vais maintenant créer les paramètres, avec des valeurs par défaut et le corps de la fonction, comme illustré à la figure 4.
Si vous comparez la figure 3 à la figure 4, vous constaterez que j'ai transposé les variables (les noms et les valeurs) sur une seule ligne et que je les ai séparées par des virgules, encapsulées entre parenthèses et placées après le nom, ce qui en fait les paramètres de la fonction. Ces paramètres ont maintenant des valeurs par défaut. J'ai laissé le calculateur de valeur actuelle tel quel. L'un des principes clés de PowerShell est « taper moins ». À la ligne 3 de la figure 4, j'aurais pu utiliser une instruction return. Vous obtenez le même comportement si vous omettez cette instruction bien qu'elle soit parfois utile lorsque vous souhaitez rompre le flux logique.
Dans cet exemple, j'illustre plusieurs méthodes d'appel de la fonction Get-PresentValue. Tout d'abord, sans paramètres, tous les paramètres par défaut sont utilisés. Les paramètres peuvent être fournis par position (voir la ligne 8 de la figure 4) ou ils peuvent être nommés (voir la ligne 9). Je vous recommande de vous documenter sur les paramètres PowerShell car ce langage prend en charge un moteur de liaison de paramètres puissant.
À venir : modification de la fonction Get-PresentValue de façon à ce qu'elle retourne un objet .NET plutôt qu'un simple texte.
PowerShell repose sur .NET
Une innovation clé de PowerShell est la capacité à passer des données en tant qu'objets entièrement typés. La figure 5 illustre le concept de création d'un objet PowerShell, de définition des propriétés, de retour de l'objet et d'optimisation du moteur PowerShell pour l'imprimer.
Figure 5 Retourner des objets entièrement typés de fonctions PowerShell
À la ligne 6, j'utilise la cmdlet New-Object qui crée une instance de l'objet .NET Framework. Je lui indique le type d'objet à créer, un PSObject qui permet un affichage cohérent des objets au sein de l'environnement PowerShell. En outre, à la ligne 6, j'utilise le paramètre -Property qui prend une table de hachage. Dans PowerShell, la syntaxe consacrée des tables de hachage est @{}. Les paires clé/valeur définies dans la table de hachage, et passées dans le paramètre -Property, sont transformées en propriétés et valeurs sur le nouveau PSObject.
En dernier lieu, à la ligne 15, j'appelle la fonction et les résultats peuvent être consultés dans le volet de sortie (bleu dégradé dans l'ISE). Remarquez que PowerShell « sait » imprimer l'objet. Je ne dois absolument pas réfléchir pour déterminer quelles propriétés imprimer ni comment les imprimer, un point fort essentiel de PowerShell.
Plages et pipelines PowerShell
J'utilise ensuite les pipelines PowerShell et je présente deux cmdlets PowerShell supplémentaires : ForEach-Object et Format-Table (voir la figure 6).
Figure 6 Plages et pipelines PowerShell
La ligne 13 est la partie la plus difficile à intégrer. Elle commence à donner une idée de la qualité souple et compositionnelle de PowerShell. Trois sections et deux canaux sont définis ici. La première section contient l'opérateur de plage (composé de deux points), la deuxième est destinée à ForEach et la dernière contient Format-Table. Je vais analyser en détail chacune d'entre elles.
Première section, 1000..10101000..1010 représente un tableau d'entiers de 1 000 à 1 010 inclus. PowerShell va maintenant les pousser un à la fois dans le pipeline dès qu'ils seront disponibles. PowerShell, comme les interpréteurs de commandes Unix/Linux, implémente un pipeline, ce qui permet à la sortie d'une cmdlet d'être redirigée comme entrée d'une cmdlet. Avec PowerShell, le pipeline est composé d'objets .NET. L'utilisation d'objets élimine le besoin d'analyser une sortie de texte arbitraire d'une commande pour extraire les données, puisque tous les objets exportent une interface cohérente (voir bit.ly/lVJarT).
Deuxième section, ForEach { Get-PresentValue $_ } Cette section utilise ForEach (également alias %) qui prend un scriptblock. Considérez un scriptblock comme une méthode anonyme (parfois qualifiée d'expression lambda dans d'autres langages). Pour en savoir plus sur ce point, consultez l'ouvrage « PowerShell in Action, Second Edition » de Bruce Payette (Manning Publications, 2011).
$_ est une variable PowerShell automatique qui contient l'objet actuel dans le pipeline. Le résultat final, un tableau de 10 entiers, se voit passer un entier à la fois à Get-PresentValue. Dans la mesure où le paramètre n'est pas nommé, je le passe en tant que paramètre de position à $Amount, comme illustré dans le volet de sortie de la figure 6.
Dernière section, Format-Table Format-Table fait ce qu'il dit ; il formate la sortie comme une table. J'utilise le paramètre -AutoSize parce qu'il ajuste la taille de la colonne en fonction de la largeur des données.
Notez que je ne gère pas l'itération par rapport à la collection et PowerShell « sait » ce qu'il doit imprimer sur l'objet poussé dans le pipeline. Cela signifie qu'il est nécessaire d'écrire moins de lignes de code, ce qui réduit le nombre de lignes à déboguer. Dans la mesure où je passe 90 % de mon temps à déboguer et les 10 % restants à écrire des bogues, cela me fait gagner du temps.
C'est l'heure de l'interface utilisateur graphique - Premier round
Il est temps d'utiliser WPK. Le script de la figure 7 produit l'interface utilisateur graphique de la figure 8. J'ai ajouté des informations de type aux paramètres de la fonction Get-PresentValue (voir la ligne 1 de la figure 7). Cela permet à d'autres utilisateurs de cette fonction de détecter aisément s'ils ont passé les mauvaises données, par exemple des chaînes au lieu de valeurs numériques.
Figure 7 New-ListView de WPK
Figure 8 Affichage de l'interface utilisateur graphique
L'essence du code original de la figure 6 a été conservée et l'appel de Get-PresentValue a été ajouté au DataContext de ListView, un contrôle WPF qui fournit l'infrastructure afin d'afficher un ensemble d'éléments de données. Les autres éléments de WPK s'intègrent avec la liaison de données WPF et définissent l'affichage dans ListView afin que les données puissent être affichées.
WPK suit le principe fondamental de PowerShell, utiliser la paire verbe-nom. Par conséquent, si je souhaite créer une fenêtre, une grille, un canevas ou une zone de liste, j'ajoute simplement « New- » (New-Window, New-Grid, New-Canvas ou New-ListBox), et ces éléments de l'infrastructure sont prêts à être utilisés.
Import-Module
Un module est un package qui contient des membres, tels que les cmdlets, les scripts, les fonctions, les variables et d'autres outils et fichiers, qui peuvent être utilisés dans PowerShell. Une fois qu'un module a été importé, vous pouvez utiliser ses membres dans votre session. Comme je l'ai mentionné plus tôt, WPK fait partie du pack PowerShell et contient plus de 700 fonctions PowerShell qui simplifient l'organisation en couches d'une interface utilisateur graphique WPF sur PowerShell.
Les lignes 17 et 18 de la figure 7 peuvent sembler inhabituelles dans la mesure où elles viennent d'un contexte WPF traditionnel. WPK prend en charge la liaison de données en surfaçant deux paramètres : DataContext et DataBinding. Le paramètre DataContext prend un scriptblock, c'est pourquoi je passe ici une ligne de code PowerShell qui crée les 10 objets de valeur actuelle qui se trouvaient ligne 13 de la figure 6. Je configure ensuite la propriété ItemsSource du ListView vers lequel effectuer la liaison ligne 18. Le paramètre DataBinding prend une table de hachage (notez le @{}). Les clés sont les noms des propriétés de l'objet de l'interface utilisateur graphique vers lequel vous souhaitez effectuer la liaison.
WPK vous permet d'écrire moins de code. La fonction New-GridViewColumn prend une chaîne (par exemple, Amount, qui est le nom d'une propriété sur l'objet émis depuis la fonction Get-PresentValue), la définit comme en-tête et effectue automatiquement la liaison de données pour vous.
J'ai commencé avec une fonction simple, Get-PresentValue, et j'ai terminé avec la sortie illustrée à la figure 8 en ajoutant des paramètres afin de la rendre réutilisable, en émettant un PSObject PowerShell .NET et en optimisant le pipeline d'objet PowerShell et un opérateur de plage pour générer des éléments de valeur actuelle. J'ai ensuite importé WPK, ajouté les objets PowerShell au DataContext d'un contrôle ListView WPF, lié le paramètre ItemsSource et créé la vue ListView avec des noms de colonne correspondant aux noms de propriété de l'objet ajouté. Et j'ai obtenu une application PowerShell/WPK simple de valeur actuelle. C'est bien, mais elle est codée en dur.
Je vais maintenant interagir avec cette application afin de voir ce qui arrive à mon investissement lorsque je modifie le montant, les intérêts et d'autres paramètres.
C'est l'heure de l'interface utilisateur graphique - Deuxième round
Je dois modifier les paramètres du script PowerShell/WPK actuel, enregistrer le fichier et réexécuter le script qui n'est pas très agile.
Je vais le retravailler afin de modifier cinq paramètres de l'interface utilisateur graphique et d'afficher de nouvelles valeurs dans ListView.
Fonction New-Range Je veux tout d'abord ajouter une fonction nommée New-Range (voir la figure 9).
Figure 9 La fonction New-Range
L'opérateur de plage fourni par PowerShell ne vous permet pas de modifier le facteur d'incrémentation. En d'autres termes, je ne peux pas spécifier (1..10 par 2). En revanche, la fonction New-Range me permet de spécifier mon propre incrément. Par conséquent, « New-Range 1 10 2 » imprime 1 3 5 7 9.
Je complète ensuite l'interface utilisateur graphique WPK en encapsulant New-ListView dans une fonction New-Window. Si vous utilisez New-ListView seule, WPK l'encapsule dans une fenêtre pour vous. La définition de New-Window me donne un contrôle accru (voir la figure 10).
Figure 10 La fonction New-Window
J'ai également élevé le DataContext de ListView jusqu'à la portée de la fenêtre et appliqué la nouvelle fonction New-Range. Je souhaite maintenant ajouter cinq zones de texte, des étiquettes et un bouton. Cela me permettra de conserver une application fonctionnelle et de modifier la sortie de Get-PresentValue. Je vais utiliser les fonctions WPK New-Grid, New-Label, New-TextBox et New-Button pour créer les contrôles dont j'ai besoin. L'utilisation de New-Grid pour créer un contrôle de grille me donne plus de souplesse pour redimensionner la fenêtre et le placement du contrôle.
Afin d'organiser l'interface utilisateur graphique, j'imbrique des grilles dans les grilles, ainsi que des contrôles. J'utilise toujours les fonctions New-Range et Get-PresentValue dans DataContext, comme illustré à la ligne 2 de la figure 11.
(cliquez sur la capture d'écran pour l'agrandir)
Figure 11 La fonction New-Grid
En outre, New-ListView se trouve toujours lignes 30-37 de la figure 11. J'ai ajouté deux paramètres à la ligne 30, -Row et -Column, qui indiquent à ListView dans quels ligne et colonne il doit se trouver, dans NewGrid défini à la ligne 5 qui utilise Rows et Columns pour organiser un grille. J'ai besoin de deux colonnes d'une largeur de 75 pixels et de trois lignes d'une hauteur de 35 pixels chacune. L'astérisque qui suit le deuxième 75 dans le paramètre Rows indique que tout l'espace disponible sera occupé.
Je place maintenant cinq paires d'étiquettes et de zones de texte dans la fenêtre, afin d'indiquer aux contrôles dans quel quadrant de la grille ils doivent s'ancrer via les paramètres Row et Column. En outre, je nomme la zone de texte afin de pouvoir y accéder ultérieurement, je lui donne une valeur par défaut avec le paramètre -Text et j'embellis les contrôles avec les paramètres Margin et HorizontalAlignment.
En dernier lieu, je place le bouton dans la grille avec la fonction New-Button. Remarquez que je place un trait de soulignement devant Calculate. Cela me permet d'accéder au bouton avec la combinaison de touches Alt-C.
Le calculateur de valeur actuelle est presque terminé. Je dois relier l'événement de clic à un code PowerShell, lire les valeurs des zones de texte, les passer comme paramètres à Get-PresentValue et le lier à ListView.
Fonction Do-Calculation
Je vais ajouter une fonction Do-Calculation qui prend un seul paramètre, $window (voir la figure 12).
Figure 12 La fonction Do-Calculation
J'appelle Do-Calculation à partir de la propriété -On-click sur New-Button, celui dont le contenu est « _Calculate ».
Do-Calculation est simple. Elle récupère les informations de toutes les zones de texte, les définit sur des variables PowerShell et les passe comme paramètres aux fonctions New-Range et Get-PresentValue. Je passe le paramètre $window (voir la ligne 2 de la figure 13), qui contient une référence à New-Window créée à la figure 10. À l'aide de cela, je peux obtenir toutes les propriétés de la fenêtre ainsi que les contrôles enfants, plus particulièrement les zones de texte. Dans la mesure où j'ai nommé chaque contrôle de zone de texte, je peux canaliser $window vers Get-ChildControl, passer le nom du contrôle et extraire le texte via la propriété .Text (voir les lignes 3-7 de la figure 12).
(cliquez sur la capture d'écran pour l'agrandir)
Figure 13 Grille terminée
En regroupant tous les détails des zones de texte, je définis $window.DataContext sur le résultat de la fonction New-Range canalisée vers Get-PresentValue, ce qui génère un tableau d'objets PowerShell contenant les résultats des calculs de PresentValue (voir les lignes 9-12 de la figure 12).
La figure 13 illustre la connexion de l'événement de clic du bouton Calculate pour appeler la fonction Do-Calculation et passer la variable $window (voir les lignes 28-29). J'ai ajouté le paramètre On_Click qui prend un ScriptBlock. J'appelle ici la fonction Do-Calculation en passant la variable $window qui est créée pour moi lorsque j'utilise la fonction New-Window. Chaque fois que je clique sur le bouton, l'écran recalcule. Remarquez que j'ai également modifié la ligne 2 de la figure 13 pour appeler aussi la fonction Do-Calculation.
Téléchargez l'application terminée dans les exemples de code source qui accompagnent cet article afin de consulter le script complet.
Une application WPF interactive et simple
J'ai présenté ici un script comportant moins de 75 lignes de code afin de créer une application WPF interactive disposée en couches sur la plateforme d'automatisation de Microsoft, PowerShell. PowerShell se manifeste dans un langage de script et dans une console de ligne de commande. Son intégration en profondeur dans .NET Framework et Windows ouvre des opportunités d'automatisation stimulantes. Cela signifie évidemment qu'il faut passer du temps à apprendre cette nouvelle plateforme. La bonne nouvelle est que vous pouvez commencer avec les éléments faciles d'accès pour devenir plus productif puis, lorsque cela s'avère nécessaire, profiter de la grande offre d'automatisation fournie par PowerShell, provenant de Microsoft et de la communauté générale PowerShell.
Le modèle de développement ad hoc et l'origine de Windows PowerShell
L'article de Doug Finke illustre parfaitement le modèle de développement ad hoc. PowerShell se différencie des autres technologies de programmation de nombreuses façons : l'accent sur le niveau élevé ; les abstractions orientées vers les tâches ; le système de type adaptatif qui normalise les différents systèmes de type (.NET, Windows Management Instrumentation [WMI], XML, ADSI, ADO, etc.) et vous permet d'ajouter des membres aux types et aux instances ; le moteur de flux de données qui élimine une grande partie de la différence d'impédance d'API que les développeurs de code doivent écrire ; et il prend en charge le modèle de développement ad hoc.
C'est dans le modèle ad hoc que vous commencez à résoudre un problème à l'aide de techniques informelles. Lorsque vous décidez de l'utiliser plus, vous le convertissez en script informel et, si vous le partagez, vous le rendez plus formel. En tant que créateurs d'outils, nous créons souvent pour des personnes ayant des jeux de compétences différents, il est donc important de répondre aux besoins et aux attentes de tout notre public. Cela signifie souvent qu'il est nécessaire de fournir une interface utilisateur graphique.
L'article de Doug commence par un script sans nom codé en dur visant à créer la PresentValue pour un montant, un taux d'intérêt fixe et une durée donnés. Il le transforme ensuite en fonction nommée avec des paramètres nommés et des valeurs initiales qui retournent une seule valeur. Ensuite, il retourne un objet qui pourra être manipulé par d'autres outils. Et en dernier lieu, il le transforme en simple interface utilisateur graphique, puis en interface plus riche. Il investit uniquement lorsqu'il le doit et chaque script ajoute de petites choses au précédent. À la fin, Doug partage son script, ce qui permet à d'autres personnes d'utiliser son outil et de suggérer des améliorations (par exemple, lorsque cela lui a été suggéré, il a « typé » ses paramètres afin que son outil ne vomisse pas lorsque quelqu'un passait des chaînes). Nous profitons tous du partage. J'ai eu un outil génial et je suis très reconnaissant à Doug. J'ai en partie pu lui montrer ma gratitude en révisant son code et proposant des suggestions. Bien que je m'y connaisse un peu en PowerShell, j'apprécie toujours énormément toutes les suggestions de la communauté sur mes scripts. [Snover est l'inventeur de Windows PowerShell et l'un de ses principaux concepteurs, avec Bruce Payette et James Truher ; consultezbit.ly/696Jor.—Ed.]
Le modèle de développement ad hoc vient de l'objectif de PowerShell d'être à la fois un shell interactif exceptionnel et un langage de script formidable. Bruce Payette, l'un des concepteurs du langage, a déclaré que la durée de vie de 99 % des scripts PowerShell commence par l'invite de commande et se termine par le retour chariot. PowerShell prend en charge un large éventail de styles de script, qui vont des commandes interactives sur une ligne à l'invite de commande aux fonctions de type dépistage qui utilisent $args, à des scripts plus formels dans lesquels les paramètres sont nommés, typés et parés d'attributs de validation, de liaison de données et d'aide. La raison pour laquelle nous avons opté pour cette approche vient du fait que j'ai écrit des tonnes de scripts d'environnement d'exécution pendant les nombreuses années où j'ai été développeur Unix. À mesure que des personnes utilisaient mes scripts et me demandaient plus de fonctionnalités, je me débarrassais des scripts et je les réécrivais en Tcl ou Perl. Je finissais souvent par me débarrasser de ceux-là également et par les réécrire complètement en C. Je me suis alors demandé pourquoi il n'existait aucun outil unique capable de couvrir ce large éventail de besoins en script, même si des problèmes différents requièrent des niveaux de formalisme et de performances différents. De cette façon, les gens pouvaient s'investir afin de devenir des experts de cet outil au lieu d'être plus ou moins compétents dans un grand ensemble d'outils. Ça m'a pris un peu de temps, mais j'ai finalement réussi à créer un outil destiné très exactement à cela. J'espère que vous appréciez PowerShell.
— Jeffrey Snover, ingénieur réputé et architecte en chef pour Windows Server.
Doug Finke*, Microsoft MVP pour Windows PowerShell, développe des logiciels chez Lab49, une entreprise qui crée des applications avancées destinées au secteur des services financiers. Depuis 20 ans, il développe et crée à l'aide de nombreuses technologies. Vous pouvez le rencontrer sur son blog, Development in a Blink, à l'adresse dougfinke.com/blog.*
Je remercie nos experts techniques d'avoir relu cet article : James Brundage, Sal Mangano, Sivabalan Muthukumar, Marco Shaw, Jeffrey Snover et Sylvain Whissell