Correções de bug no WMF 5.1#Bug Fixes in WMF 5.1#

Correções de bugBug fixes

Os seguintes bugs importantes foram corrigidos no WMF 5.1:The following notable bugs are fixed in WMF 5.1:

A descoberta automática do módulo honra totalmente $env:PSModulePathModule auto-discovery fully honors $env:PSModulePath

A descoberta automática do módulo (carregando módulos automaticamente sem um Import-Module explícito ao chamar um comando) foi introduzida no WMF 3.Module auto-discovery (loading modules automatically without an explicit Import-Module when calling a command) was introduced in WMF 3. Quando introduzido, o PowerShell verificava comandos no $PSHome\Modules antes de usar $env:PSModulePath.When introduced, PowerShell checked for commands in $PSHome\Modules before using $env:PSModulePath.

O WMF 5.1 altera esse comportamento para honrar $env:PSModulePath completamente.WMF 5.1 changes this behavior to honor $env:PSModulePath completely. Isso permite que um módulo de autoria do usuário que define comandos fornecidos pelo PowerShell (por exemplo, Get-ChildItem) seja carregado automaticamente, substituindo corretamente o comando interno.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.

Redirecionamento de arquivos não embute mais -Encoding UnicodeFile redirection no longer hard-codes -Encoding Unicode

Em versões anteriores do PowerShell, era impossível controlar a codificação do arquivo usada pelo operador de redirecionamento de arquivo, por exemplo, Get-ChildItem > out.txt, porque o PowerShell adicionava -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.

Do WMF 5.1 em diante, agora é possível alterar a codificação do arquivo de redirecionamento configurando $PSDefaultParameterValues:Starting with WMF 5.1, you can now change the file encoding of redirection by setting $PSDefaultParameterValues:

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

Corrigida uma regressão no acesso a membros do System.Reflection.TypeInfoFixed a regression in accessing members of System.Reflection.TypeInfo

Uma regressão introduzida no WMF 5.0 se rompeu ao acessar membros de System.Reflection.RuntimeType, por exemplo, [int].ImplementedInterfaces.A regression introduced in WMF 5.0 broke accessing members of System.Reflection.RuntimeType, e.g. [int].ImplementedInterfaces. Esse bug foi corrigido no WMF 5.1.This bug has been fixed in WMF 5.1.

Corrigidos alguns problemas com objetos COMFixed some issues with COM objects

O WMF 5.0 introduziu um novo associador de COM para chamar métodos em objetos COM e o acesso às propriedades de objetos COM.WMF 5.0 introduced a new COM binder for invoking methods on COM objects and accessing properties of COM objects. Esse novo associador melhorou consideravelmente o desempenho, mas também introduziu alguns bugs que foram corrigidos no WMF 5.1.This new binder improved performance significantly but also introduced some bugs which have been fixed in WMF 5.1.

Conversões de argumento não eram sempre executadas corretamenteArgument conversions were not always performed correctly

No exemplo a seguir:In the following example:

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

O método SendKeys espera uma cadeia de caracteres, mas o PowerShell não converteu o caractere para uma cadeia de caracteres, adiando a conversão para IDispatch::Invoke, que usa VariantChangeType para fazer a conversão, que, neste exemplo, resultou em enviar as chaves “1”, “7” e “3”, em vez da chave Volume.Mute esperada.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.

Objetos COM enumeráveis nem sempre eram tratados corretamenteEnumerable COM objects not always handled correctly

O PowerShell normalmente enumera a maioria dos objetos enumeráveis, mas uma regressão introduzida no WMF 5.0 impedia a enumeração de objetos COM que implementam IEnumerable.PowerShell normally enumerates most enumerable objects, but a regression introduced in WMF 5.0 prevented the enumeration of COM objects that implement IEnumerable. Por exemplo:For example:

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

$x = Get-COMDictionary

No exemplo acima, o WMF 5.0 gravou incorretamente Scripting.Dictionary no pipeline, em vez de enumerar os pares chave-valor.In the above example, WMF 5.0 incorrectly wrote the Scripting.Dictionary to the pipeline instead of enumerating the key/value pairs.

Esta alteração também aborda o problema 1752224 no ConnectThis change also addresses issue 1752224 on Connect

[ordered] não era permitido dentro de classes[ordered] was not allowed inside classes

O WMF 5.0 introduziu classes com validação de literais de tipo usados em classes.WMF 5.0 introduced classes with validation of type literals used in classes.
[ordered] parece um literal de tipo, mas não é um tipo .NET verdadeiro.[ordered] looks like a type literal but is not a true .NET type. O WMF 5.0 relatou incorretamente um erro no [ordered] dentro de uma classe:WMF 5.0 incorrectly reported an error on [ordered] inside a class:

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

A ajuda em tópicos “Sobre” com várias versões não funcionaHelp on About topics with multiple versions does not work

Antes do WMF 5.1, se houvesse várias versões de um módulo instaladas e elas compartilhassem um tópico de ajuda, por exemplo, about_PSReadline, help about_PSReadline retornaria vários tópicos sem uma maneira óbvia de exibir a ajuda real.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.

O WMF 5.1 corrige isso retornando a ajuda para a versão mais recente do tópico.WMF 5.1 fixes this by returning the help for the latest version of the topic.

Get-Help não oferece uma maneira de especificar para qual versão você quer obter ajuda.Get-Help does not provide a way to specify which version you want help for. Para solucionar esse problema, navegue até o diretório de módulos e exibir a ajuda diretamente com uma ferramenta como seu editor favorito.To work around this, navigate to the modules directory and view the help directly with a tool like your favorite editor.

A leitura do powershell.exe do STDIN parou de funcionarpowershell.exe reading from STDIN stopped working

Os clientes usam o powershell -command - de aplicativos nativos para executar o PowerShell passando o script por meio do STDIN, mas infelizmente isso não está funcionando devido a outras alterações no host do 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-10https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/15854689-powershell-exe-command-is-broken-on-windows-10

O powershell.exe cria um pico no uso da CPU durante a inicializaçãopowershell.exe creates spike in CPU usage on startup

O PowerShell usa uma consulta de WMI para verificar se ele foi iniciado por meio de Política de Grupo para evitar um atraso no logon.PowerShell uses a WMI query to check if it was started via Group Policy to avoid causing delay in login. A consulta de WMI acaba injetando o tzres.mui.dll em cada processo no sistema, uma vez que a classe Win32_Process de WMI tenta recuperar informações do fuso horário 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. Isso resulta em um grande aumento no uso da CPU no wmiprvse (o host de provedor de WMI).This results in a large CPU spike in wmiprvse (the WMI provider host). A correção é usar chamadas de API do Win32 para obter as mesmas informações em vez de usar o WMI.Fix is to use Win32 API calls to get the same information instead of using WMI.