Votes from Connect: 24

Original Date Submitted: 10/25/2012 1:54:42 PM

Description:
********Contact Information********
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 768650
***************************************

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
In PSv3, the pipeline can be stopped. Select-Object supports this with its -First parameter by raising a (non-public) StopUpstreamCommandsException exception.

It is of great value to be able to stop the pipeline if your mission is completed before the emitting cmdlet has provided all results.

In fact, the PS pipeline would gain a completely new "feature". Currently, it is a memory throttle and provides realtime feedback at the cost of performance. If stopping the pipeline was something available to users, it could also be a generic means of running cmdlets only partially.

Select-Object is a great start but you do not always know beforehand how many elements you need. So it would be beneficial to have a Stop-Pipeline cmdlet or at least a public StopUpstreamCommandsException that a script programme can throw.

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

Repro Steps:
none applicable

Expected Results:

Internal BugId: 3902

It is annoying when I’m debugging in the ISE and an unhandled exception occurs - the ISE debugger just exits. It gives me no chance to debug the issue that caused the unhandled exception while still debugging. The importance of stopping **in** the debugger, is that I can examine the state of variables throughout the call stack which can be very helpful in tracking down "why" the unhandled exception occurred.

So first, I want to set an "unhandled" exception breakpoint that would cause PowerShell to “break into” the debugger on any unhandled exception i.e. put the brakes on just before the script is about to exit.

Second, scripts can get a bit happy with try/catch and you can run into scenarios where exceptions get swallowed. While this scenario is a bit more corner-case, I have found it extremely useful to be able to set an exception breakpoint such that the debugger stops at the point it first sees the specified exception type thrown.

Since PowerShell allows for exception such as “throw ‘Oops’”, setting a breakpoint on exception type [RuntimeException] might also warrant use of the Action parameter e.g. if ($_.Exception.Message -eq ‘oops’) {break}.

So perhaps there is two new parameters sets added. One with the Parameter -UnhandledException (of type [switch]) and another with the parameters -Exception (of type [string[]] - names of exception types) and -Action (of type [scriptblock])

I have just installed Windows Management Framework (WMF) 5.0 RTM on my Windows
7 SP1 and tested it. `Get-ChildItem -LiteralPath -Include -Recurse` started to
work differently in v5.

This command

Get-ChildItem -Path $PSHOME -Include *.exe -Recurse

gets expected *powershell.exe* and *powershell_ise.exe*.

The same command with `-LiteralPath` instead of `-Path`

Get-ChildItem -LiteralPath $PSHOME -Include *.exe -Recurse

in PowerShell v5 RTM unexpectedly gets all items in `$PSHOME`.

I cannot test this with previous versions right now (by the way,
`PowerShell.exe -Version 2` seems to have the same issue in v5 RTM). But I
believe in PowerShell v3 and v4 this was not the case. I found this issue
because this command

Get-ChildItem -LiteralPath <path> -Include <some temp files> -Recurse | Remove-Item

tried to remove all files in `<path>` instead of specified temp files.
This command used to work work as expected before installing v5 RTM.

Here is confirmation from Stack Overflow:
http://stackoverflow.com/questions/33684178/powershell-5-get-childitem-literalpath-doesnt-work-with-include-anymore

Votes from Connect: 35

Original Date Submitted: 9/22/2010 9:56:58 PM

Description:
********Contact Information********
Handle: Joel "Jaykul" Bennett
Site Name: PowerShell
Feedback ID: 603415
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Currently PowerShell has it's own system (based on type.ps1xml files) for creating extension methods -- while this would have been admirable in the .Net 1.1 or 2.0 era, in the modern .Net Framework we already have Extension methods, and they do not work in PowerShell.

As more and more of the .Net Framework itself and 3rd Party APIs begins to depend on extension methods to create "fluent" programming interfaces, it is critical that PowerShell support pre-compiled .Net extension methods.

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

Repro Steps:
Expected Results:

Internal BugId: 2690

At the moment to use encrypted credentials in partial configurations with ConfigurationNames it is necessary to share certificate across all nodes, else decryption will fail. I believe it should be technically possible to use more dynamic approach:
- encrypt MOF with certificate for which pull server has private key
- during registration client would send over certificate for which it has private key so that pull server can encrypt any credentials in the mofs sent to this node with this certificate.

At the moment it's manual labour on the operators side: make sure that encrypt/decrypt just works. It would be nice if pull server could do more of the heavy-lifting here.

In order to register external module dependencies (dependencies living in another repository), the name has to be registered in a string array property within the PSData Hashtable property in the PrivateData section in the psd1 manifest like so for registering module 'psFtp':

PrivateData = @{
PSData = @{
# ExternalModuleDependencies
ExternalModuleDependencies = @('psFtp')
}
} # End of PrivateData hashtable

However, the new-modulemanifest doesn't have an -ExternalModuleDepencies parameter, nor is it possible to register externalmoduledependencies like so:

-PrivateData @{ PSData = @{ ExternalModuleDependencies = @('psFtp') } }

Which from a client perspective of the the existing new-modulemanifest api, would be an intuitive way of setting ExternalModuleDependencies.

Suggestion is:
Either make -ExternalModuleDependencies available as parameter or let the processing of the -PrivateData arguments handle nested hashtables (such as PSData in this case).

Votes from Connect: 8

Original Date Submitted: 8/22/2014 11:58:54 PM

Description:
********Contact Information********
Handle: Aaron Jensen
Site Name: PowerShell
Feedback ID: 952833
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Currently, when using comment-based help, you're limited to one line of code for an example. This is extremely limiting, especially when trying to document DSC resources, since they span multiple lines by default. Also, some examples would be more useful with some extra lines. The current alternative is to use XML-based help, but the MAML schema is extremely verbose and complicated.

What I'd like to see is everything until the first empty line is treated as a code sample, e.g.

.EXAMPLE
User CreateUser
{
Username = 'fubar';
Credential = $credential;
}

Demonstrates the minimum amount of code needed to create a user with the `User` resource.

Would render as:

-------------------------- EXAMPLE 1 --------------------------
PS C:\> User CreateUser
{
Username = 'fubar';
Credential = $credential;
}

Demonstrates the minimum amount of code needed to create a user with the `User` resource.

Other ideas:

* Prefix on each line of the example code
* Use the ` at the end of each line to mean "continue the example code onto the next line".

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

Repro Steps:
Expected Results:

Internal BugId: 8968

Votes from Connect: 10

Original Date Submitted: 12/10/2011 12:21:15 AM

Description:
********Contact Information********
Handle: JoshGav
Site Name: PowerShell
Feedback ID: 712796
***************************************

Frequency: Always Happens
Regression: Yes, this happens in previous released versions

Problem Description:
The final delimiter in a here-string is defined as newline-quotemarks-atsign. This means that the "@ has to be at the beginning of the final line, with no whitespace preceding it. This ruins attempts at tab indentation in scripts and functions. Whitespace should be allowed as part of the ending pattern between the newline and quotemarks so that tab indentation can be cleanly utilized.

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

Repro Steps:
If a here-string is typed as follows:
$str = @"
a string
"@
it will not be evaluated properly.

Expected Results:
Allow the previously indicated string as a here-string, ignoring the extra whitespace between the final newline and ".

Internal BugId: 3186

We've been lucky, from what I'm gathering from web searches! Until December last year, Exchange Online Powershell cmdlet help was available using Get-Help in the shell. However, after the Christmas break, the only response we get is:

Get-Help : Exception calling "Invoke" with "0" argument(s): "Cannot find path '' because it does
not exist."
At line:1 char:1
+ Get-Help Get-Mailbox
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-Help], MethodInvocationException
+ FullyQualifiedErrorId : CmdletInvocationException

It's the same issue irrespective of the cmdlet.

Consequently, I'm forced to contend with painful searches of the documentation website for information of the relevant cmdlets.

Raised this question on the Github Exchange documentation site (https://github.com/MicrosoftDocs/office-docs-powershell/issues/2440) and Chris Davis, who noticed the issue since June, suggested I raise a support case. So not sure this is the right place to do so.

Powershell 5.1 on both Windows 7/10

When defining a function, I would like to use an environment variable as the default value. If the environment variable exists and has a value that value will be used. For example,

function Get-Info ([Alias("name")] [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true)] [string] $projectName = $env:Project_Name)
{
}

Instead of having to passing in the Project Name for each call I would like to store it in an environment variable. When I do it would allow me to call Get-Info with no parameters and the value in the environment variable would be used. If the environment variable does not exist or is empty the user would be prompted for a value if it was not provided on the command line.
I tried writing the code as I have above but it never seemed to work. Even when the environment variable was set I was always prompted for projectName.
I know I could remove the mandatory attribute and add code in my function to set to the environment variable if it exists. But it would be much easier if what I am proposing was possible.

Votes from Connect: 4

Original Date Submitted: 11/14/2015 5:05:21 AM

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

Problem Description:
To require the exact version of a module, I need a RequiredVersion option in #Requires.

The ModuleVersion key in the #Requires -Module hashtable: @{ModuleName=''; ModuleVersion=''} behaves as a minimum version requirement. Not all versions of all modules are backward-compatible. With the proliferation of versions, including side-by-side in PowerShell 5.0, we need to be able to require a particular version.

Also, about_Requires describes the ModuleVersion, but does not mention that it's a minimum (because I didn't know that when I wrote it -- should have tested!).

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

Repro Steps:

Internal BugId: 15970

At some point in the 5.0 time period, Update-Help installed About topic files in the en-US directory for the PSWorkflow module with .txt (not .help.txt) file name extensions.

e.g. about_Foreach-Parallel.txt

Later, this was fixed and Update-Help installed the same help files in the same directory with the (correct) ".help.txt" file name extension.

e.g. about_Foreach-Parallel.help.txt

Now, the PSWorkflow\en-US directory has 9 pairs of files that are identical except for the file name extension.

about_ActivityCommonParameters.help.txt
about_ActivityCommonParameters.txt
about_Checkpoint-Workflow.help.txt
about_Checkpoint-Workflow.txt
about_Foreach-Parallel.help.txt
about_Foreach-Parallel.txt
about_InlineScript.help.txt
about_InlineScript.txt
about_Parallel.help.txt
about_Parallel.txt
about_Sequence.help.txt
about_Sequence.txt
about_Suspend-Workflow.help.txt
about_Suspend-Workflow.txt
about_WorkflowCommonParameters.help.txt
about_WorkflowCommonParameters.txt
about_Workflows.help.txt
about_Workflows.txt

Get-Help should ignore the .txt files (must have changed in 4.0), but it does not. Instead, it finds both .txt and .help.txt. So, when you run Get-Help, instead of displaying help for the topic, it lists the duplicate base names.

PS C:\ps-test> Get-Help about_Foreach-Parallel

Name Category Module Synopsis
---- -------- ------ --------
about_ForEach-Parallel HelpFile Describes the ForEach
about_Foreach-Parallel HelpFile Describes the ForEach

I'm not sure why Get-Help is recognizing About.txt files.

But, we had a similar problem in a module when we shipped a file with corrected capitalization in the base name.

about_FileName.help.txt
about_filename.help.txt

We might want to tweak Get-Help so that when it detects an exact duplicate base name, it displays the content in the newest file.

Also, in modules, Get-Help should display the help only for the version of the module that it's processing. That would allow module authors to update help topic names without causing unintended duplicates.

Hello!

The PowerShell Gallery currently qualifies 'Scripts' by name only. For example, if someone has already published Some-Script, I have no way to publish my own Some-Script, even if the original is related only in name, has major functional differences, etc.

It would be helpful to allow qualifying these. Perhaps resolve by date published first (i.e. compatible with current system), while allowing qualification by username, similar to how GitHub handles this.

Thus, I could install RamblingCookieMonster\Some-Script, even if EvilDoer\Some-Script already existed.

The same design could also be extended to modules, although those seem less likely to conflict (this may change if the open source community adopts PowerShell and starts publishing more modules, so... might be worth looking at...)

Cheers!