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: 18

Original Date Submitted: 6/21/2013 12:49:43 AM

Description:
********Contact Information********
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 790586
***************************************

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

Problem Description:
In the PS ISE v3 Script Pane, if you use the undo or redo commands (Ctrl+Z and Ctrl+Y respectively), the caret does not jump to the text being undone/redone, and the view does not scroll to the text being undone/redone either. So if the text being changed is outside of the visible area, you don't know what changes are being undone/redone. This is a real problem when you have scripts that are hundreds or thousands of lines long.

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

Repro Steps:
Open a new file in the Script Pane and type in a bunch of text so that there is more text than can be viewed on the screen at a time. Change some text at the top of the file, save the file, then scroll to the bottom of the file and perform an Undo (Ctrl+Z). Notice that the dirty flag appears on the file's tab so you can see that it was changed, but you cannot see the text that was undone.

Expected Results:
When you perform and Undo or Redo, the file should scroll so that the text being undone/redone is visible, and the caret should also jump to the text being undone/redone.

Internal BugId: 4263

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

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!

In 5.0, objects returned from a script will appear in the console only after the script has completely finished if no formatting data is defined for that object type.

Example:

Write-Warning "Before"
Get-Service E* | select Status, Name, DisplayName
Write-Warning "After"

Output:

WARNING: Before

WARNING: After
Status Name DisplayName
------ ---- -----------
Stopped EapHost Extensible Authentication Protocol
Running EFS Encrypting File System (EFS)
Running eventlog Windows Event Log
Running EventSystem COM+ Event System

Details
- This did not happen before PowerShell 5.0
- This happens both in the PowerShell console and ISE
- The issue affects all objects that have no formatting data, for example:
<anything> | Select-Object -Property …
[pscustomobject]@{one=1;two=2}
Get-Acl C:\
Get-Location
- Output that is sent to other streams is not affected (errors, Write-Host, Write-Warning, Write-Verbose etc.)
- The issue only occurs in table view (i.e. does not happen if the object has more than 4 properties)
- The issue also occurs if the script output is piped to a file, but not if it is piped to another command (e.g. Out-GridView).

This issue can create unexpected results for scripts that worked fine in previous PowerShell versions. Running this (contrived) script will highlight the issue:

$RandomProcess = Get-Process | Get-Random
Write-Host "Random process:"
$RandomProcess | select Name, ID
Read-Host "Press Enter to stop the listed process"
$RandomProcess | Stop-Process -WhatIf

What makes this potentially dangerous is that making subtle changes to the code (e.g. in the previous examples, removing the select command) could change the output significantly. At the very least it violates the "principle of least surprise".

This may be caused by the new default formatter waiting for all pipeline objects so it can display them in the new auto-sized column layout (essentially an implicit Format-Table -AutoSize). It would be better if the behavior reverted to the previous formatting style for “unknown” objects so it displays all output in the proper order.

Workarounds:

- If the objects do not really need to be sent to the pipeline, append “| Out-Host" or "| Out-String" to the command generating the objects.