Votes from Connect: 9

Original Date Submitted: 6/16/2015 3:12:31 AM

Description:
Contact Information
Handle: Ondrej Sevecek
Site Name: PowerShell
Feedback ID: 1437366

Frequency: PowerShell
Regression: run the mentioned script on Windows 10.0.10074 in its built-in PowerShell 5.

Problem Description:
When I run the following on Windows 10.0.10074 in PowerShell 5, it does not work for user members of the local group:

$admins = [ADSI] 'WinNT://./Administrators,group'

foreach ($oneMember in $admins.Members()) {

$oneMemberName = $oneMember.GetType().InvokeMember('Name', 'GetProperty', $null, $oneMember, $null)
Write-Host $oneMemberName

}

The error is: Error while invoking GetType. Could not find member.

While the code works fine on any other OS (tested on Windows XP, Vista, 7, 8, 8.1) within PowerShell 2,3,4. It also works fine within PowerShell 2 on Windows 10.0.10074.

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

Repro Steps:
run the mentioned script on Windows 10.0.10074 in its built-in PowerShell 5.

Expected Results:
it should run well :-)

Internal BugId: 15570

In PowerShell ISE, if you invoke the exit command, it closes the entire application regardless of how many tabs you have open. It would be better if the exit command simply closed the current tab (if you have multiple tabs open) or the entire application if you only have one runspace open. This would prevent accidentally closing runspaces that you wanted to go back to just because you used the all-too-familiar exit command.

Also, making this change would address this issue within PowerShell ISE: when you invoke exit, the Runspace.StateChanged event is only fired for the current/active runspace (tab), even if you have multiple tabs open, so all tabs other than the current one that want to do cleanup of some resource when the runspace is closed cannot do so.

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])

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).

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

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

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

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.

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

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.

aboutActivityCommonParameters.help.txt
aboutActivityCommonParameters.txt
aboutCheckpoint-Workflow.help.txt
aboutCheckpoint-Workflow.txt
aboutForeach-Parallel.help.txt
aboutForeach-Parallel.txt
aboutInlineScript.help.txt
aboutInlineScript.txt
aboutParallel.help.txt
aboutParallel.txt
aboutSequence.help.txt
aboutSequence.txt
aboutSuspend-Workflow.help.txt
aboutSuspend-Workflow.txt
aboutWorkflowCommonParameters.help.txt
aboutWorkflowCommonParameters.txt
aboutWorkflows.help.txt
aboutWorkflows.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

aboutForEach-Parallel HelpFile Describes the ForEach
aboutForeach-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.

aboutFileName.help.txt
aboutfilename.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.

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.