Oplossingen voor problemen in WMF 5.1#Bug Fixes in WMF 5.1#

Oplossingen voor problemenBug fixes

De volgende belangrijke fouten zijn verholpen in WMF 5.1:The following notable bugs are fixed in WMF 5.1:

Module-auto-discovery volledig zich houdt aan $env:PSModulePathModule auto-discovery fully honors $env:PSModulePath

Module-auto-discovery (modules laden zonder een expliciete Import-Module bij het aanroepen van een opdracht automatisch) werd geïntroduceerd in WMF 3.Module auto-discovery (loading modules automatically without an explicit Import-Module when calling a command) was introduced in WMF 3. Wanneer geïntroduceerd, PowerShell gecontroleerd op opdrachten in $PSHome\Modules voordat u $env:PSModulePath.When introduced, PowerShell checked for commands in $PSHome\Modules before using $env:PSModulePath.

WMF 5.1 verandert dit gedrag in acht neemt $env:PSModulePath volledig.WMF 5.1 changes this behavior to honor $env:PSModulePath completely. Hiermee kunt u een door de gebruiker opgestelde module waarmee wordt gedefinieerd door de PowerShell-opdrachten (bijvoorbeeld Get-ChildItem) automatisch geladen en de ingebouwde opdracht correct te overschrijven.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.

Omleiding van het bestand niet langer vastgelegd -Encoding UnicodeFile redirection no longer hard-codes -Encoding Unicode

In alle eerdere versies van PowerShell, is het niet mogelijk om te bepalen de bestandscodering die bijvoorbeeld worden gebruikt door de omleidingsoperator bestand Get-ChildItem > out.txt omdat PowerShell toegevoegd -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.

Beginnen met WMF 5.1, kunt u nu wijzigen de bestandscodering van omleiding door in te stellen $PSDefaultParameterValues:Starting with WMF 5.1, you can now change the file encoding of redirection by setting $PSDefaultParameterValues:

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

Er is een regressie bij het openen van leden van opgelost System.Reflection.TypeInfoFixed a regression in accessing members of System.Reflection.TypeInfo

Een regressie die is geïntroduceerd in WMF 5.0 verbroken toegang tot leden van System.Reflection.RuntimeType, bijvoorbeeld [int].ImplementedInterfaces.A regression introduced in WMF 5.0 broke accessing members of System.Reflection.RuntimeType, e.g. [int].ImplementedInterfaces. Deze fout is verholpen in WMF 5.1.This bug has been fixed in WMF 5.1.

Sommige problemen opgelost met COM-objectenFixed some issues with COM objects

WMF 5.0 geïntroduceerd voor een nieuwe COM binder voor aanroepen methoden van COM-objecten en toegang tot eigenschappen van COM-objecten.WMF 5.0 introduced a new COM binder for invoking methods on COM objects and accessing properties of COM objects. Deze nieuwe binder prestaties aanzienlijk verbeterd, maar ook enkele problemen die zijn verholpen in WMF 5.1 geïntroduceerd.This new binder improved performance significantly but also introduced some bugs which have been fixed in WMF 5.1.

Argument conversies zijn niet altijd correct uitgevoerdArgument conversions were not always performed correctly

In het volgende voorbeeld:In the following example:

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

De methode SendKeys verwacht een tekenreeks, maar PowerShell heeft niet de tekens naar een tekenreeks converteren, het uitstellen van de conversie naar IDispatch::Invoke die VariantChangeType voor de conversie, die in dit voorbeeld heeft geresulteerd in het verzenden van de sleutels '1', '7' en '3' in plaats daarvan gebruikt van de verwachte Volume.Mute-sleutel.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.

Inventariseerbare COM-objecten niet altijd correct worden verwerktEnumerable COM objects not always handled correctly

PowerShell normaal gesproken de meeste invoeroverzicht objecten worden opgesomd, maar een regressie die is geïntroduceerd in WMF 5.0 niet meer aanmelden bij de inventarisatie van COM-objecten die als IEnumerable is geïmplementeerd.PowerShell normally enumerates most enumerable objects, but a regression introduced in WMF 5.0 prevented the enumeration of COM objects that implement IEnumerable. Bijvoorbeeld:For example:

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

$x = Get-COMDictionary

In het bovenstaande voorbeeld geschreven WMF 5.0 ten onrechte de Scripting.Dictionary aan de pijplijn in plaats van het inventariseren van de sleutel/waarde-paren.In the above example, WMF 5.0 incorrectly wrote the Scripting.Dictionary to the pipeline instead of enumerating the key/value pairs.

Dit ook wijzigen van adressen uitgeven 1752224 op verbinding makenThis change also addresses issue 1752224 on Connect

[ordered] is niet toegestaan in klassen[ordered] was not allowed inside classes

WMF 5.0 geïntroduceerd klassen met validatie van het type letterlijke waarden in de klassen.WMF 5.0 introduced classes with validation of type literals used in classes. [ordered] ziet eruit als een letterlijke type, maar is geen waar .NET-type.[ordered] looks like a type literal but is not a true .NET type. WMF 5.0 heeft een fout niet juist gerapporteerd op [ordered] binnen een klasse:WMF 5.0 incorrectly reported an error on [ordered] inside a class:

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

Help-informatie op over onderwerpen met meerdere versies werkt nietHelp on About topics with multiple versions does not work

Voordat u WMF 5.1, als er meerdere versies van een module geïnstalleerd en ze allemaal een help-onderwerp, bijvoorbeeld gedeeld about_PSReadline, help about_PSReadline retourneerde meerdere onderwerpen met geen duidelijke manier om de echte Help-informatie weer te geven.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 corrigeert dit door te retourneren van de help voor de meest recente versie van het onderwerp.WMF 5.1 fixes this by returning the help for the latest version of the topic.

Get-Help biedt geen een manier om op te geven welke versie u hulp wilt.Get-Help does not provide a way to specify which version you want help for. Om dit te omzeilen, Ga naar de map modules en de Help rechtstreeks met een hulpprogramma zoals uw favoriete editor.To work around this, navigate to the modules directory and view the help directly with a tool like your favorite editor.

lezen van STDIN PowerShell.exe niet meer werktpowershell.exe reading from STDIN stopped working

Klanten gebruiken powershell -command - van native apps uit te voeren PowerShell deze door te geven in het script via STDIN helaas Hiermee is verbroken vanwege andere wijzigingen aan de consolehost.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 maakt piek in CPU-gebruik bij het opstartenpowershell.exe creates spike in CPU usage on startup

PowerShell maakt gebruik van een WMI-query om te controleren of deze werd gestart via Groepsbeleid om te voorkomen dat vertraging veroorzaken bij aanmelden.PowerShell uses a WMI query to check if it was started via Group Policy to avoid causing delay in login. De WMI-query eindigt tzres.mui.dll injecteren in elk proces op het systeem, omdat de Win32_Process WMI-klasse probeert op te halen van informatie over de lokale tijdzone.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. Dit resulteert in een grote piek van de CPU in wmiprvse (de WMI-provider host).This results in a large CPU spike in wmiprvse (the WMI provider host). Oplossing is het gebruik van Win32 API-aanroepen naar dezelfde gegevens in plaats van WMI ophalen.Fix is to use Win32 API calls to get the same information instead of using WMI.