Votes from Connect: 4

Original Date Submitted: 11/28/2015 5:59:49 AM

Description:
Contact Information
Handle: Keith Hill MVP
Site Name: PowerShell
Feedback ID: 2065573

Problem Description:
Right now it is too hard to write a 100% reliable script that can run in any particular user's PowerShell console. The crux of the problem is that global session state is so varied amongst individual users it is hard to anticipate all possibilities such as:

•Command proxies
•Imported (auto or explicit) modules that implement the same named command (but semantically different)
•Redirected aliases
•Defined variables you weren't expecting to be defined
•Removed globals you were expecting to be defined
•Already loaded module (but wrong version)

I have seen this issue with an early install script for the powershell-vscode extension for VSCode. The script uses the v5 Expand-Archive command to extract a zip. Seems very reasonable but the script fails for anyone who has the PSCX module installed because PSCX has an Expand-Archive command that uses different parameter names. It is unreasonable to expect script authors to anticipate all these potential variations of global session state. One workaround I have resorted to, is to run all scripts I get from someone else in a new PowerShell session loaded with -NoProfile. This helps but really, I shouldn't have to do that.

IMO it is pretty rare for a script to require anything from the global session state. And if it does require it, it would be better for the script to somehow declare what it needs (usually it's a global variable). Far more often, I want to write my scripts with some sort of #Requires NewGlobalSessionState directive that tells PowerShell to not use any of the user's global session state. With this, I'm stating that I will import every module that I need and that I specifically don't want to use any of the modules that happen to already be loaded by the user. Command resolution should be based on what the script imports - nothing else. Ditto for alias resolution. Yeah I know I shouldn't be using aliases in my script but I don't want a user redefining the Where alias to break my script.

My understanding is that the PSDefaultParameterValues behavior in a script was changed for V5 to address this sort of issue - user's global session state breaking scripts. The value of PSDefaultParameterValues is cleared for script scope. I think this concept (cleared for script scope) needs more consideration and should be applied to way more than just PSDefaultParameterValues.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 2065573 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=2065573).

Repro Steps:

Internal BugId: 16016

Votes from Connect: 3

Original Date Submitted: 11/26/2015 2:36:27 AM

Description:
Contact Information
Handle: Firgeis
Site Name: PowerShell
Feedback ID: 2057856

Frequency: Always Happens
Regression: I do not know if this issue existed previously

Problem Description:

PS C:\Users\Administrator> Update-Help
Update-Help : Failed to update Help for the module(s) 'ConfigCI' with UI culture(s) {en-US} : The
HelpInfoUri key in the module manifest must resolve to a container or root URL on a website where
stored. The HelpInfoUri 'https://technet.microsoft.com/library/cc732148.aspx' does not resolve to
At line:1 char:1
+ Update-Help
+ ~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (:) [Update-Help], Exception

+ FullyQualifiedErrorId : InvalidHelpInfoUri,Microsoft.PowerShell.Commands.UpdateHelpCommand

PS C:\Users\Administrator> $PSVersionTable.PSVersion

Major Minor Build Revision

5 0 10586 0

PS C:\Users\Administrator> [System.Environment]::OSVersion.Version

Major Minor Build Revision

10 0 10586 0

Product Studio item created by Connect Synchronizer due to creation of feedback ID 2057856 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=2057856).

Repro Steps:
Expected Results:

Internal BugId: 16010

Votes from Connect: 8

Original Date Submitted: 11/5/2015 5:13:13 AM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 1981963

Problem Description:
Scripts are designed to be either dot-sourced, called, or much less often, both. Yet the vast majority of scripts out there don't have anything in place to make sure that they were invoked the right way. This can lead to a lot of confusion for script consumers that could be easily avoided.

I would like to see the #requires statement expanded with the addition of two new parameters: -DotSource and -CallOperator. When a script is invoked, PowerShell will check to see what the script requires (what invocation methods it supports), and if the invocation method that was used isn't supported by the script, then PowerShell could display an appropriate error message to the user so that they can invoke it correctly.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1981963 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1981963).

Repro Steps:

Internal BugId: 15952

Votes from Connect: 3

Original Date Submitted: 8/11/2015 6:16:25 PM

Description:
Contact Information
Handle: SamiKoskivaara
Site Name: PowerShell
Feedback ID: 1654123

Frequency: PowerShell
Regression: Create two enums, explicitly define a variable to have named enum type, assign value to that variable from another enum type. It does not give an error message that the value is not from the right enum type.

Problem Description:
If I define two enums 'Size' and 'PizzaType'

Enum Size {

Small

Medium

Large

}

Enum PizzaType {

Margherita

Vegetariana

Peperoni

}

and then I want to explicitly say that my variable $a is [PizzaType] it allows me to assign [Size] enum type too to that variable:

[PizzaType]$a = [Size]::Small
> $a
Margherita

It should not allow this because $a variable is set to have a type of [PizzaType] enum.

In C# it works like it should:

Error CS0266
Cannot implicitly convert type 'ConsoleApplication1.Program.PizzaType' to 'ConsoleApplication1.Program.Size'. An explicit conversion exists (are you missing a cast?)

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1654123 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1654123).

Repro Steps:
Create two enums, explicitly define a variable to have named enum type, assign value to that variable from another enum type. It does not give an error message that the value is not from the right enum type.

Expected Results:
Should give an error message and not allow to assign enum value from another enum.

Internal BugId: 15727

Votes from Connect: 4

Original Date Submitted: 7/8/2015 11:36:23 AM

Description:
Contact Information
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 1519608

Frequency: PowerShell
Regression: 1. Use the Invoke-WebRequest command to call a protocol-relative URL
2. Exception occurs: "iwr : Invalid URI: The hostname could not be parsed."

Problem Description:
Invoke-WebRequest doesn't work with protocol-relative URLs.

http://www.paulirish.com/2010/the-protocol-relative-url/

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1519608 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1519608).

Repro Steps:
1. Use the Invoke-WebRequest command to call a protocol-relative URL
2. Exception occurs: "iwr : Invalid URI: The hostname could not be parsed."

Expected Results:
Invoke-WebRequest should work with protocol-relative URLs

Internal BugId: 15632

Votes from Connect: 3

Original Date Submitted: 6/29/2015 1:59:05 AM

Description:
Contact Information
Handle: June Blender
Site Name: PowerShell
Feedback ID: 1483941

Frequency: Documentation
Regression:
PS C:\ps-test> get-help Configuration

NAME

Configuration

SYNTAX

Configuration [[-ModuleDefinition] <Object>] [[-ResourceDefinition] <Object>] [[-OutputPath] <Object>] [[-Name] <Object>]

[[-Body] <scriptblock>] [[-ArgsToBody] <hashtable>] [[-ConfigurationData] <hashtable>] [[-InstanceName] <string>]

[<CommonParameters>]

ALIASES

None

REMARKS

Get-Help cannot find the Help files for this cmdlet on this computer. It is displaying only partial help.

    -- To download and install Help files for the module that includes this cmdlet, use Update-Help.

PS C:> Get-Help aboutLanguageKeywords | Out-String -Stream | Select-String Configuration
PS C:>

Problem Description:
Configuration is a critical keyword and function, but the function does not have a help topic (Get-Help Configuration) and the keyword is not listed in aboutLanguageKeywords.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1483941 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1483941).

Repro Steps:
PS C:\ps-test> get-help Configuration

NAME

Configuration

SYNTAX

Configuration [[-ModuleDefinition] <Object>] [[-ResourceDefinition] <Object>] [[-OutputPath] <Object>] [[-Name] <Object>]

[[-Body] <scriptblock>] [[-ArgsToBody] <hashtable>] [[-ConfigurationData] <hashtable>] [[-InstanceName] <string>]

[<CommonParameters>]

ALIASES

None

REMARKS

Get-Help cannot find the Help files for this cmdlet on this computer. It is displaying only partial help.

    -- To download and install Help files for the module that includes this cmdlet, use Update-Help.

PS C:> Get-Help aboutLanguageKeywords | Out-String -Stream | Select-String Configuration
PS C:>

Expected Results:
Both command should return help.

Internal BugId: 15613

Votes from Connect: 3

Original Date Submitted: 6/9/2015 1:49:33 AM

Description:
Contact Information
Handle: Joel 'Jaykul' Bennett
Site Name: PowerShell
Feedback ID: 1413156

Frequency: PowerShell
Regression: Register-PSRepository -Name LocalFolder -Source "$Pwd" -Publish "$Pwd"
Publish-Module -Name C:\Users\Joel\Projects\Modules\Autoload -Repository LocalFolder -NuGetApiKey (Get-Random)

Problem Description:
The NuGetApiKey should not be mandatory on Publish Module, because it's not actually mandatory.

For instance, if I'm publishing to a local folder, I don't need to specify a key!

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1413156 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1413156).

Repro Steps:
Register-PSRepository -Name LocalFolder -Source "$Pwd" -Publish "$Pwd"
Publish-Module -Name C:\Users\Joel\Projects\Modules\Autoload -Repository LocalFolder -NuGetApiKey (Get-Random)

Expected Results:
The key should be optional, since it's only useful on certain types of NuGet feeds.

Internal BugId: 14552

Votes from Connect: 3

Original Date Submitted: 5/23/2015 6:40:05 AM

Description:
Contact Information
Handle: jskiba
Site Name: PowerShell
Feedback ID: 1357781

Frequency: PowerShell
Regression: within powershell console

navigate to "HKLM:\SOFTWARE\Classes*"
run "gci" to find an available subkey name (eg: "OpenWithList")
run "get-acl .\OpenWithList
Verify CPU load time, and registry enumeration via procmon

Problem Description:
The asterisk “” character is valid as a registry key name. When navigating to the path “HKLM:\SOFTWARE\Classes*” and attempting to query ACL for values such as those in “HKLM:\SOFTWARE\Classes*\OpenWithList” , everything under “Classes” is queried, treating the “” as a wildcard and not a path character. This leads to long wait time and max CPU time as each object in “HKLM:\SOFTWARE\Classes*” is enumerated. This can be seen using procmon. get-childitem does not seem to show this behavior but get-acl does.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1357781 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1357781).

Repro Steps:
within powershell console

navigate to "HKLM:\SOFTWARE\Classes*"
run "gci" to find an available subkey name (eg: "OpenWithList")
run "get-acl .\OpenWithList
Verify CPU load time, and registry enumeration via procmon

Expected Results:
Retrieve acl for "OpenWithList" without querying all other entries in the path at "*".

Internal BugId: 14509

Votes from Connect: 4

Original Date Submitted: 5/13/2015 9:02:25 PM

Description:
Contact Information
Handle: Matt McNabb
Site Name: PowerShell
Feedback ID: 1329164

Problem Description:
It would be nice to have cmdlet help include information about any error types that might be thrown and whether they are terminating or non-terminating. This would be a benefit when writing scripts that have formal error-handling with try/catch so we can properly filter the catch blocks and add -ErrorAction Stop where necessary.

Usage could be something like:

Get-Help Get-Something -Errors

Or:

Get-Help Get-Something -Exceptions

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1329164 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1329164).

Repro Steps:

Internal BugId: 14462

Votes from Connect: 3

Original Date Submitted: 5/3/2015 6:39:12 PM

Description:
Contact Information
Handle: Remco Kapinga
Site Name: PowerShell
Feedback ID: 1299466

Problem Description:
Invoke-ScriptAnalyzer flags this as a Warning:

if ($item -ne $null) { .. }

And suggest that we should write this comparison as:

if ($null -ne $item) { .. }

That makes code less readable (yoda-speak). This reminds us of the c language defect with if(a = null) { .. } versus if(a == null) { .. }

I don't see the point of this rule in PowerShell, and the suggested construct makes code less readable.

Please remove this Rule (or explain the reasoning behind it, if it really is an issue)!

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1299466 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1299466).

Repro Steps:

Internal BugId: 14435