Considérations relatives à la création de modules PowerShell

Ce document inclut des instructions relatives à la création d’un module pour des performances optimales.

Création du manifeste d’un module

Un manifeste de module qui n’utilise pas les instructions suivantes peut avoir un impact notable sur les performances générales de PowerShell même si le module n’est pas utilisé dans une session.

La découverte automatique des commandes analyse chaque module pour déterminer quelles commandes le module exporte et cette analyse peut être coûteuse. Les résultats de l’analyse de module sont mis en cache par utilisateur, mais le cache n’est pas disponible lors de la première exécution, ce qui est un scénario classique avec des conteneurs. Pendant l’analyse du module, si les commandes exportées peuvent être entièrement déterminées à partir du manifeste, une analyse plus coûteuse du module peut être évitée.

Lignes directrices

• Dans le manifeste du module, n’utilisez pas de caractères génériques dans les entrées AliasesToExport, CmdletsToExportet FunctionsToExport.

• Si le module n’exporte pas les commandes d’un type particulier, spécifiez cela explicitement dans le manifeste en spécifiant @(). Une entrée manquante ou $null équivaut à spécifier le caractère générique *.

Les éléments suivants doivent être évités dans la mesure du possible :

@{
    FunctionsToExport = '*'

    # Also avoid omitting an entry, it's equivalent to using a wildcard
    # CmdletsToExport = '*'
    # AliasesToExport = '*'
}

Utilisez plutôt :

@{
    FunctionsToExport = 'Format-Hex', 'Format-Octal'
    CmdletsToExport = @()  # Specify an empty array, not $null
    AliasesToExport = @()  # Also ensure all three entries are present
}

Éviter CDXML

Lorsque vous décidez comment implémenter votre module, il existe trois choix principaux :

• Binaire (généralement C#)
• Script (PowerShell)
• CDXML (fichier XML encapsulant CIM)

Si la vitesse de chargement de votre module est importante, CDXML est à peu près un ordre de grandeur plus lent qu’un module binaire.

Un module binaire charge le plus rapide, car il est compilé à l’avance et peut utiliser NGen pour la compilation JIT une fois par machine.

Un module de script charge généralement un peu plus lentement qu’un module binaire, car PowerShell doit analyser le script avant de compiler et de l’exécuter.

Un module CDXML est généralement beaucoup plus lent qu’un module de script, car il doit d’abord analyser un fichier XML qui génère ensuite un peu de script PowerShell qui est ensuite analysé et compilé.