Résolutions de bogues dans WMF 5.1#Bug Fixes in WMF 5.1#

Résolutions de boguesBug fixes

Les bogues importants suivants sont résolus dans WMF 5.1 :The following notable bugs are fixed in WMF 5.1:

La détection automatique de module respecte entièrement $env:PSModulePathModule auto-discovery fully honors $env:PSModulePath

La détection automatique de module (chargement automatique des modules sans Import-Module explicite lors de l’appel d’une commande) a été introduite dans WMF 3.Module auto-discovery (loading modules automatically without an explicit Import-Module when calling a command) was introduced in WMF 3. Lors de l’introduction, PowerShell vérifiait la présence des commandes dans $PSHome\Modules avant d’utiliser $env:PSModulePath.When introduced, PowerShell checked for commands in $PSHome\Modules before using $env:PSModulePath.

WMF 5.1 modifie ce comportement pour honorer $env:PSModulePath complètement.WMF 5.1 changes this behavior to honor $env:PSModulePath completely. Ainsi, un module créé par l’utilisateur qui définit des commandes fournies par PowerShell (par exemple, Get-ChildItem) peut être chargé automatiquement et remplacer correctement la commande intégrée.This allows for a user-authored module that defines commands provided by PowerShell (e.g. Get-ChildItem) to be auto-loaded and correctly overriding the built-in command.

La redirection de fichiers ne code plus en dur -Encoding UnicodeFile redirection no longer hard-codes -Encoding Unicode

Dans toutes les versions précédentes de PowerShell, il était impossible de contrôler l’encodage de fichier utilisé par l’opérateur de redirection de fichier, par exemple Get-ChildItem > out.txt, car PowerShell ajoutait -Encoding Unicode.In all previous versions of PowerShell, it was impossible to control the file encoding used by the file redirection operator, e.g. Get-ChildItem > out.txt because PowerShell added -Encoding Unicode.

À compter de WMF 5.1, vous pouvez modifier l’encodage de fichier de la redirection en définissant $PSDefaultParameterValues :Starting with WMF 5.1, you can now change the file encoding of redirection by setting $PSDefaultParameterValues:

$PSDefaultParameterValues["Out-File:Encoding"] = "Ascii"

Correction d’une régression dans l’accès aux membres de System.Reflection.TypeInfoFixed a regression in accessing members of System.Reflection.TypeInfo

Une régression introduite dans WMF 5.0 interrompait l’accès aux membres de System.Reflection.RuntimeType, par exemple [int].ImplementedInterfaces.A regression introduced in WMF 5.0 broke accessing members of System.Reflection.RuntimeType, e.g. [int].ImplementedInterfaces. Ce bogue a été résolu dans WMF 5.1.This bug has been fixed in WMF 5.1.

Résolution de certains problèmes liés aux objets COMFixed some issues with COM objects

WMF 5.0 a introduit un nouveau binder COM pour appeler des méthodes sur des objets COM et accéder aux propriétés des objets COM.WMF 5.0 introduced a new COM binder for invoking methods on COM objects and accessing properties of COM objects. Ce nouveau binder a amélioré les performances de manière significative, mais il a également introduit des bogues qui ont été résolus dans WMF 5.1.This new binder improved performance significantly but also introduced some bugs which have been fixed in WMF 5.1.

Les conversions d’arguments n’étaient pas toujours effectuées correctementArgument conversions were not always performed correctly

Dans l’exemple suivant :In the following example:

$obj = New-Object -ComObject WScript.Shell
$obj.SendKeys([char]173)

La méthode SendKeys attend une chaîne, mais PowerShell n’a pas converti le caractère en chaîne, ce qui diffère la conversion en IDispatch::Invoke, qui utilise VariantChangeType pour effectuer la conversion. Dans cet exemple, cela provoque l’envoi des clés « 1 », « 7 » et « 3 » au lieu de la clé Volume.Mute attendue.The SendKeys method expects a string, but PowerShell did not convert the char to a string, deferring the conversion to IDispatch::Invoke, which uses VariantChangeType to do the conversion, which in this example resulted in sending the keys '1', '7', and '3' instead of the expected Volume.Mute key.

Les objets COM énumérables ne sont pas toujours gérés correctementEnumerable COM objects not always handled correctly

PowerShell énumère normalement la plupart des objets énumérables, mais une régression introduite dans WMF 5.0 empêchait l’énumération des objets COM qui implémentent IEnumerable.PowerShell normally enumerates most enumerable objects, but a regression introduced in WMF 5.0 prevented the enumeration of COM objects that implement IEnumerable. Par exemple :For example:

function Get-COMDictionary
{
    $d = New-Object -ComObject Scripting.Dictionary
    $d.Add('a', 2)
    $d.Add('b', 2)
    return $d
}

$x = Get-COMDictionary

Dans l’exemple ci-dessus, WMF 5.0 écrivait incorrectement le Scripting.Dictionary dans le pipeline au lieu d’énumérer les paires clé/valeur.In the above example, WMF 5.0 incorrectly wrote the Scripting.Dictionary to the pipeline instead of enumerating the key/value pairs.

Cette modification résout également le problème 1752224 sur Connect.This change also addresses issue 1752224 on Connect

[ordered] n’était pas autorisé à l’intérieur des classes[ordered] was not allowed inside classes

WMF 5.0 a introduit des classes avec la validation des littéraux de type utilisée dans les classes.WMF 5.0 introduced classes with validation of type literals used in classes. [ordered] ressemble à un littéral de type, mais n’est pas un vrai type .NET.[ordered] looks like a type literal but is not a true .NET type. WMF 5.0 signalait de façon erronée une erreur sur [ordered] à l’intérieur d’une classe :WMF 5.0 incorrectly reported an error on [ordered] inside a class:

class CThing
{
    [object] foo($i)
    {
        [ordered]@{ Thing = $i }
    }
}

L’aide sur les rubriques de procédures avec plusieurs versions ne fonctionne pasHelp on About topics with multiple versions does not work

Avant WMF 5.1, si plusieurs versions d’un module étaient installées et que toutes partageaient une rubrique d’aide, par exemple about_PSReadline, help about_PSReadline retournait plusieurs rubriques sans aucun moyen évident d’afficher l’aide réelle.Before WMF 5.1, if you had multiple versions of a module installed and they all shared a help topic, for example, about_PSReadline, help about_PSReadline would return multiple topics with no obvious way to view the real help.

WMF 5.1 résout ce problème en retournant l’aide de la version la plus récente de la rubrique.WMF 5.1 fixes this by returning the help for the latest version of the topic.

Get-Help n’offre aucun moyen de spécifier la version pour laquelle vous souhaitez obtenir de l’aide.Get-Help does not provide a way to specify which version you want help for. Pour contourner ce problème, accédez au répertoire de modules et affichez l’aide directement avec un outil tel que votre éditeur favori.To work around this, navigate to the modules directory and view the help directly with a tool like your favorite editor.

Impossible de lire powershell.exe à partir de STDINpowershell.exe reading from STDIN stopped working

Les clients utilisent powershell -command - à partir d’applications natives pour passer des commandes PowerShell dans le script par le biais de STDIN. Malheureusement, cela ne fonctionne plus en raison d’autres modifications apportées à l’hôte de la console.Customers use powershell -command - from native apps to execute PowerShell passing in the script via STDIN unfortunately this was broken due to other changes it the console host.

https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/15854689-powershell-exe-command-is-broken-on-windows-10

powershell.exe crée un pic d’utilisation du processeur au démarragepowershell.exe creates spike in CPU usage on startup

PowerShell utilise une requête WMI pour vérifier s’il a été démarré par le biais d’une stratégie de groupe afin de ne pas causer de retard au niveau de la connexion.PowerShell uses a WMI query to check if it was started via Group Policy to avoid causing delay in login. La requête WMI finit par injecter tzres.mui.dll dans chaque processus sur le système, car la classe WMI Win32_Process tente de récupérer des informations sur le fuseau horaire local.The WMI query ends up injecting tzres.mui.dll into every process on the system since the WMI Win32_Process class attempts to retrieve local timezone information. Il en résulte une hausse soudaine de l’utilisation du processeur dans wmiprvse (hôte du fournisseur WMI).This results in a large CPU spike in wmiprvse (the WMI provider host). Pour y remédier tout en obtenant les mêmes informations, utilisez des appels d’API Win32 à la place de WMI.Fix is to use Win32 API calls to get the same information instead of using WMI.