WMF 5.1의 버그 수정#Bug Fixes in WMF 5.1#

버그 수정Bug fixes

WMF 5.1에서는 다음과 같은 주목할 만한 버그가 수정되었습니다.The following notable bugs are fixed in WMF 5.1:

모듈 자동 검색에서 완전히 적용함 $env:PSModulePathModule auto-discovery fully honors $env:PSModulePath

모듈 자동 검색(명령을 호출할 때 명시적 Import-Module 없이 모듈을 자동으로 로드)이 WMF 3에 도입되었습니다.Module auto-discovery (loading modules automatically without an explicit Import-Module when calling a command) was introduced in WMF 3. 도입될 때 PowerShell에서는 $env:PSModulePath를 사용하기 전에 $PSHome\Modules에 있는 명령을 확인했습니다.When introduced, PowerShell checked for commands in $PSHome\Modules before using $env:PSModulePath.

WMF5.1에서는 $env:PSModulePath를 완전히 적용하도록 이 동작을 변경합니다.WMF 5.1 changes this behavior to honor $env:PSModulePath completely. 따라서 PowerShell에서 제공하는 명령(예: Get-ChildItem)을 정의하는 사용자 작업 모듈이 자동으로 로드되고 기본 제공 명령을 올바로 재정의할 수 있습니다.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.

파일 리디렉션에서 더 이상 하드 코드하지 않음 -Encoding UnicodeFile redirection no longer hard-codes -Encoding Unicode

PowerShell의 모든 이전 버전에서는 PowerShell에서 -Encoding Unicode를 추가했으므로 파일 리디렉션 연산자(예: Get-ChildItem > out.txt)를 사용하여 파일 인코딩을 제어할 수 없습니다.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.

WMF 5.1부터 이제 $PSDefaultParameterValues를 설정하여 리디렉션의 파일 인코딩을 변경할 수 있습니다.Starting with WMF 5.1, you can now change the file encoding of redirection by setting $PSDefaultParameterValues:

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

구성원 액세스에서의 회귀 수정 System.Reflection.TypeInfoFixed a regression in accessing members of System.Reflection.TypeInfo

WMF 5.0에 도입된 회귀가 System.Reflection.RuntimeType의 구성원(예: [int].ImplementedInterfaces) 액세스를 중단시켰습니다.A regression introduced in WMF 5.0 broke accessing members of System.Reflection.RuntimeType, e.g. [int].ImplementedInterfaces. 이 버그는 WMF 5.1에서 수정되었습니다.This bug has been fixed in WMF 5.1.

COM 개체의 몇 가지 문제 수정Fixed some issues with COM objects

WMF 5.0에서는 COM 개체에 대한 메서드를 호출하고 COM 개체의 속성에 액세스하는 새로운 COM 바인더를 도입했습니다.WMF 5.0 introduced a new COM binder for invoking methods on COM objects and accessing properties of COM objects. 이 새 바인더는 성능을 크게 향상했지만 몇 가지 버그도 도입했습니다. 이 버그는 WMF 5.1에서 수정되었습니다.This new binder improved performance significantly but also introduced some bugs which have been fixed in WMF 5.1.

인수 변환이 올바로 수행되지 않을 수도 있었음Argument conversions were not always performed correctly

다음 예제에서,In the following example:

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

SendKeys 메서드에는 문자열이 필요하지만 PowerShell은 문자를 문자열로 변환하지 않고 IDispatch::Invoke에서 변환을 수행하게 했습니다. IDispatch::Invoke는 VariantChangeType을 사용하여 변환을 수행하므로 이 예에서는 Volume.Mute 키 대신 '1', '7' 및 '3' 키가 보내졌습니다.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.

열거 가능 COM 개체가 올바로 처리되지 않을 수도 있음Enumerable COM objects not always handled correctly

PowerShell에서는 대부분의 열거 가능 개체를 정상적으로 열거하지만 WMF 5.0에 도입된 회귀로 인해 IEnumerable을 구현하는 COM 개체가 열거되지 못했습니다.PowerShell normally enumerates most enumerable objects, but a regression introduced in WMF 5.0 prevented the enumeration of COM objects that implement IEnumerable. 예:For example:

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

$x = Get-COMDictionary

위의 예에서 WMF 5.0은 키/값 쌍을 열거하지 않고 Scripting.Dictionary를 파이프라인에 잘못 썼습니다.In the above example, WMF 5.0 incorrectly wrote the Scripting.Dictionary to the pipeline instead of enumerating the key/value pairs.

이 변경으로 issue 1752224 on Connect(Connect의 문제 1752224)도 해결됩니다.This change also addresses issue 1752224 on Connect

[ordered]는 클래스 내에서 허용되지 않았음[ordered] was not allowed inside classes

WMF 5.0에서는 클래스에 사용된 형식 리터럴의 유효성을 검사하는 클래스를 도입했습니다.WMF 5.0 introduced classes with validation of type literals used in classes. [ordered]는 형식 리터럴로 보이지만 실제 .NET 형식이 아닙니다.[ordered] looks like a type literal but is not a true .NET type. WMF 5.0에서는 클래스 내에 있는 [ordered]에 대해 오류를 잘못 보고했습니다.WMF 5.0 incorrectly reported an error on [ordered] inside a class:

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

여러 버전이 있는 정보 항목에 대한 도움말이 작동하지 않음Help on About topics with multiple versions does not work

WMF5.5.1 이전에는 모듈의 여러 버전이 설치되어 있고 이들 버전이 모두 about_PSReadline과 같은 하나의 도움말 항목을 공유한 경우 help about_PSReadline에서 여러 항목을 반환하므로 실제 도움말을 볼 수 있는 방법이 명확히 없었습니다.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에서는 항목의 최신 버전에 대한 도움말을 반환하여 이 문제를 수정합니다.WMF 5.1 fixes this by returning the help for the latest version of the topic.

Get-Help에서는 도움말이 필요한 버전을 지정하는 방법을 제공하지 않습니다.Get-Help does not provide a way to specify which version you want help for. 이 문제를 해결하려면 모듈 디렉터리로 이동하고 즐겨 사용하는 편집기와 같은 도구에서 직접 도움말을 표시합니다.To work around this, navigate to the modules directory and view the help directly with a tool like your favorite editor.

powershell.exe가 STDIN에서 읽기 작동이 중지됨powershell.exe reading from STDIN stopped working

고객이 네이티브 앱에서 powershell -command -를 사용하여 PowerShell을 실행함으로써 STDIN을 통해 스크립트를 전달하는 기능이 아쉽게도 콘솔 호스트의 다른 변경 내용으로 인해 손상되었습니다.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의 CPU 사용량이 급증함powershell.exe creates spike in CPU usage on startup

PowerShell은 로그인에 지연이 발생하지 않도록 WMI 쿼리를 사용하여 그룹 정책을 통해 시작되었는지를 확인합니다.PowerShell uses a WMI query to check if it was started via Group Policy to avoid causing delay in login. WMI Win32_Process 클래스는 현지 표준 시간대 정보를 검색하려고 시도하므로 WMI 쿼리는 시스템의 모든 프로세스로 tzres.mui.dll을 삽입하게 됩니다.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. 따라서 wmiprvse(WMI 공급자 호스트)에서 CPU 사용량이 엄청나게 급증하게 됩니다.This results in a large CPU spike in wmiprvse (the WMI provider host). 해결 방법은 WMI를 사용하는 대신 Win32 API 호출을 사용하여 같은 정보를 가져오는 것입니다.Fix is to use Win32 API calls to get the same information instead of using WMI.