Votes from Connect: 3

Original Date Submitted: 11/7/2014 10:07:44 PM

Description:

Contact Information
Handle: sba
Site Name: PowerShell
Feedback ID: 1023770

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

Problem Description:
I have a script that contains the following code:

--------------8<----------------
function Get-ScriptDirectory{

$Invocation = (Get-Variable MyInvocation -Scope 1).Value

try {

    Split-Path $Invocation.MyCommand.Path -ea 0

}

catch {

    Write-Warning 'You need to call this function from within a saved script.'

}

}

$scriptdir = Get-ScriptDirectory

Set-Location $scriptdir -ErrorAction Stop
--------------8<----------------

(this originates from PS2.0 days)

The script runs fine, except if it's run from MSBuild using:

<Target Name="AfterClean">

<Message Text="Cleaning old generated files" Importance="normal" />

<Exec Command="powershell -noprofile -executionpolicy unrestricted -file $(ProjectDir)RemoveOldGeneratedFiles.ps1 ... />

</Target>

When run this way, I get:

Cleaning old generated files
powershell -noprofile -executionpolicy unrestricted -file ...\RemoveOldGeneratedFiles.ps1 ...
The property 'Value' cannot be found on this object. Verify that the property exists.At ....\RemoveOldGeneratedFiles.ps1:34 char:2
+ $Invocation = (Get-Variable MyInvocation -Scope 1).Value
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException

  + FullyQualifiedErrorId : PropertyNotFoundStrict

EXEC : warning : You need to call this function from within a saved script. [...foo.csproj]

If I add a Write-Host command to the Get-ScriptDirectory function before the "$Invocation = ..." line, the problem very mysteriously disappears.

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

Repro Steps:
Run a script with the aforementioned code via MSBuild

Expected Results:
No exception raised by Get-Variable MyInvocation -Scope 1).Value

Internal BugId: 13091

Votes from Connect: 11

Original Date Submitted: 5/29/2013 2:52:43 AM

Description:
Contact Information
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 788806

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

Problem Description:

If you try and run a PowerShell script from File Explorer (e.g. Windows Explorer) by double clicking on it, or from the context menu using Open With -> Windows PowerShell the script will not run; instead the PowerShell console will display an error that the given file path is not valid, since only the first portion (up to the first space) of the script file path is passed to powershell.exe. The solution is a simple registry tweak to enclose the path passed to the powershell executable in double quotes.

Essentially you just need to change the key:
HKEYCLASSESROOT\Applications\powershell.exe\shell\open\command

from this:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "%1"

to this:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "& &quot;%1&quot;"

I explain this problem and the registry workaround in more detail on my blog at http://blog.danskingdom.com/fix-problem-where-windows-powershell-cannot-run-script-whose-path-contains-spaces/.

I found a related bug report (https://connect.microsoft.com/PowerShell/feedback/details/718060/power-shell-scripts-fail-at-startup-if-file-path-has-a-space-in-it) which seems to be a specific instance of this more general problem.

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

Repro Steps:
1 - Create a powershell script with spaces in the file name or the directory that the script is in.
2 - Try running the powershell script by double clicking on it, or right-clicking it and choosing Open With -> Windows PowerShell.

Expected Results:

The script should run, but instead an error is thrown that it cannot find the script.

Internal BugId: 4225

Votes from Connect: 114

Original Date Submitted: 1/11/2013 5:50:47 PM

Description:
Contact Information
Handle: Arnaud Petitjean
Site Name: PowerShell
Feedback ID: 776313

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

Problem Description:
* Unlike the previous versions (1.0 and 2.0) *, in PowerShell 3.0 there are no help files available in French language.

I would consider missing help as top priority here. Even for peoples who can read English, there is a big danger to misunderstood something. Reading documentation in a foreign language can be very challenging.

Calling the -online Help every time I need verbose English Help, is no solution. Because I am sitting in a corporate Network with Proxy and no Internet Access!

I have downloaded the English HelpFiles with Save-Help -UICulture 'en-US' but I can't access this Helpfiles. Because the Help depends on the UI Culture of my current Windows setting.
I can't display them without changind my UI Culture in Windows!
Should I switch my Windows settings allways if I need verbose English help?

I'd like the Help system to AUTOMATICALLY display French help by default but if not available then to "failover" to the English version if installed.

Please also consider to add the -Culture parameter to Get-Help, in order to:

Get-Help Get-Comand -Culture "en-US" -Full # should display the English verbose Help
Get-Help Get-Comand -Culture "fr-FR" -Full # should display the French verbose Help

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

Repro Steps:
Expected Results:

Internal BugId: 4073

Votes from Connect: 11

Original Date Submitted: 9/29/2012 1:53:59 AM

Description:

Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 765261

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

Problem Description:
The Invoke-RestMethod cmdlet in PowerShell v3 is truncating the results that come back from the Windows Azure REST API (querying for a list of ServiceBus queues), formatted as a XML AtomPub document. Within the results of the AtomPub document, only every other AtomPub "title" is returned from Invoke-RestMethod, rather than a complete result set.

This behavior can be confirmed by using the parameters -PassThru -OutFile to export the AtomPub document to a file. After this, you can cast the file contents to a XML document using the [XML] type accelerator, which then has the correct number of "titles."

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

Repro Steps:
1. Call the Windows Azure ListQueues API using Invoke-RestMethod.

http://msdn.microsoft.com/en-us/library/windowsazure/hh780759.aspx

1. Examine output from Invoke-RestMethod. Only every other queue will be returned, rather than a complete listing.

Expected Results:
The Invoke-RestMethod cmdlet should return a complete array of all AtomPub "titles" instead of truncating them.

Internal BugId: 3846

Votes from Connect: 10

Original Date Submitted: 4/21/2012 9:43:26 PM

Description:
Contact Information
Handle: PowerShellDon
Site Name: PowerShell
Feedback ID: 738071

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

Problem Description:
I suggest a Register-Module cmdlet, which can be used to register a given module, on a given machine, optionally within a given AD site, as being publicly available. Registration would be in DNS, likely as SRV records (much like an AD domain controller).

"Get-Module -List" would then list local modules as well as modules advertised in DNS for the user's current site (or modules advertised with no site preference). Module auto discovery would not be expected to work with these DNS-registered modules. However, Import-Module, when given just a module name (vs a path), would implicitly remote DNS-registered modules if the specified module was not installed locally.

Because this would probably expose the remoting "second hop" problem more frequently, remoting error messages should ideally be changed to identify situations where the second hop has not worked, and to suggest reading up on CredSSP.

The intent is to let senior administrators designate machines from which specified modules should be implicitly remoted - rather than having to locally install modules, and rather than letting other administrators decide for themselves where to remote modules from.

The SRV records used to advertise a module could also, potentially, advertise a specific port for Remoting, specify whether SSL was required, specify an endpoint (session configuration) name, etc - everything Import-Module would need to implicitly spin up a PSSession and import the module.

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

Repro Steps:
n/a

Expected Results:
n/a

Internal BugId: 3540

Votes from Connect: 17

Original Date Submitted: 3/26/2012 6:09:59 PM

Description:
Contact Information
Handle: Peter Kriegel
Site Name: PowerShell
Feedback ID: 733298

Frequency: Sometimes Happens
Regression: I don't know if this issue existed previously

Problem Description:
Make it Possible to save PowerShell scripts in a compiled format (binary byte-code).

Since PowerShell V 3.0 uses the DLR, every PowerShell V 3.0 script has to be compiled during the first run of the script. This may have a speed disadvantage. To speed up the execution of scripts, it may be useful to store scripts in a compiled binary format and run them without an additional compilation step.

This may be useful in the following scenarios:

*  Logonscripts

* calling large amounts of scripts

With the possibility to store PowerShell Scripts in a compiled form, even Administrators are able to produce binary files, without forcing them to use .Net developer Tools like Visual Studio or equal. (producing .dll Assemblys !?)

As side effect, the source code of a script is not direct and easy readable.
Some PowerShell script developers may have the need to protect their knowledge and not give away, easy to read, plain text scripts. Scripts that are stored in a binary format, having the advantage that they are not readable, without an additional re-engineering step.

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

Repro Steps:
Expected Results:
Higher Runtime Speed,
Administrators can create assemblys which can be used by other Programs.
Lightweight script read-protection.

Internal BugId: 3467

Votes from Connect: 13

Original Date Submitted: 3/5/2012 6:41:31 PM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 728747

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

Problem Description:
In PowerShell 3.0, the Test-Path cmdlet supports two new parameters: NewerThan and OlderThan. Both parameters accepts a DateTime object and return $true if the object's LastWriteTime is less/greater than the specified date.

One of the tasks IT admins need to perform often is getting old files. It would be great if Get-ChildItem could support those parameters as well, allowing us to filter objects based on a datetime value without the need to use the Where-Object cmdlet.

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

Repro Steps:
Expected Results:

Internal BugId: 3393

Votes from Connect: 11

Original Date Submitted: 1/20/2012 4:28:52 AM

Description:

Contact Information
Handle: Atrus1701
Site Name: PowerShell
Feedback ID: 719412

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
I've created a script that will run as Administrator and needs to mount two drives. One drive is mounted using 'subst' and the other through 'net use'. Before mounting, I check to see if the drive is already in use and unmount them if they are. Afterward, I mount these drives to the path I need. It seems that if a drive is already mounted, either through 'subst' or 'net use', then deleted, and re-added, then the drive is mounted but unreachable in PowerShell. However, if you open a new PowerShell instance, the drive is reachable. This error also occurs when I try to 'subst' to local folders.

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

Repro Steps:
subst I: <folder>
subst I: /d
subst I: <folder>

Expected Results:
When using, DriveNotFoundException occurs and Test-Path returns false.

Internal BugId: 3299

Votes from Connect: 13

Original Date Submitted: 1/6/2012 5:20:17 AM

Description:
Contact Information
Handle: Steve Murawski
Site Name: PowerShell
Feedback ID: 716857

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

Problem Description:
When Import-Module is called with one of the Alias, Cmdlet, Function, or Variable parameters, but not any of the others, the module only partially loads (based on what parameter you specified), but attempting to access commands that were not directly referenced by the specified parameter results in (replace the name of the command with whatever command you want to test with).

The term 'Get-DataCollectorSet' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:4 char:1
+ Get-DataCollectorSet -Server PatrolCar
+ ~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Get-DataCollectorSet:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

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

Repro Steps:
Import-Module PSDiagnostics -Alias @()
Get-Module PSDiagnostics | fl * #verify the exported functions are there
Get-Command -Module PSDiagnostics #No commands will be shown

Expected Results:
This should import all the functions, variables, and cmdlets, as no value was specified for those parameters. They should remain the default values.

If you just ran import-module, the equivalent parameter values (default values) would be * (for everything). The minute you specify one value, the remainder default to none.

Internal BugId: 3265

Votes from Connect: 10

Original Date Submitted: 12/30/2011 6:54:11 PM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 716021

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

Problem Description:
In PowerShell 3.0 CTP2 we can configure how automatic importing works by using the PSDisableModuleAutoLoading environment variable. However, when we launch a fresh instance of PowerShell, the variable is not present in the Env: drive which makes it very hard to discover.

One has to know the variable name in advance in order to set its value.

I suggest to include the variable in the Env: drive so it can be easily discovered using auto completion:

$env:PS<tab>

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

Repro Steps:
Expected Results:

Internal BugId: 3254

Votes from Connect: 12

Original Date Submitted: 12/10/2011 6:51:41 AM

Description:
Contact Information
Handle: Oisin Grehan
Site Name: PowerShell
Feedback ID: 712875

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

Problem Description:
So, I don't know if anyone else noticed it yet, but the WSMAN drive is no longer mounted at start up: It's autoloaded. The problem I have with this is that it doesn't seem to be a valid candidate for get-command, even if wsman: were a function (which it's not, it appears, unlike "c:") So the problem here is unless you know it's going to work, you're not going to find it. Get-PSProvider shows nothing, and Get-PSDrive also comes up short.

It would seem that the analgous thing to do would be to have Get-PSProvider show unloaded providers (I was going to suggest get-psdrive but showing unmounted drives is just weird/wrong) like Get-Command shows unloaded commands.

I suggest the following syntax: get-psprovider -listavailable

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

Repro Steps:
there is no way to see what providers are available, and their default drive triggers that would autoload the implementation.

Expected Results:
get-psprovider -listavailable

show providers and default drives.

Internal BugId: 3189

Votes from Connect: 16

Original Date Submitted: 12/10/2011 12:34:32 AM

Description:
Contact Information
Handle: Oisin Grehan
Site Name: PowerShell
Feedback ID: 712798

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

Problem Description:
Currently we have to treat snapins and modules differently in powershell. Registered snapins won't show up in the output of get-module -listavailable. I would like to see a preference variable added that would allow snapins to be listed, loaded and unloaded with the module cmdlets. For example, the quest AD snapin, the TFS power tools etc don't show up in the output of get-module -list as they are registered as snapins using installutil.

I would imagine it would not be too hard to autogenerate a stub module manifest from the snapin assembly metadata, or failing that, just load the snapin assembly directly with the get-module code path.

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

Repro Steps:
n/a

Expected Results:
n/a

Internal BugId: 3187

Votes from Connect: 10

Original Date Submitted: 12/10/2011 12:03:55 AM

Description:
Contact Information
Handle: JoshGav
Site Name: PowerShell
Feedback ID: 712794

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

Problem Description:
Often the user wants to retrieve the full help when executing a command, not just the default help topics. Add a "-??" parameter to complement the "-?" parameter, with the -?? returning the same as Get-Help -Full.

This feedback came from a student at a PFE PowerShell workshop.

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

Repro Steps:
Expected Results:

Internal BugId: 3185

Votes from Connect: 18

Original Date Submitted: 9/23/2011 7:23:48 PM

Description:
Contact Information
Handle: Steve Murawski
Site Name: PowerShell
Feedback ID: 690427

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

Problem Description:
The new Where-Object syntax does not properly evaluate calling a method on a property that returns a Boolean.

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

Repro Steps:
This will error:
Get-Command | ? parameters.containskey('Credential') | sort name

This will not:
Get-Command | ? {$_.parameters.containskey('Credential')} | sort name

Expected Results:
Both commands should list out any commands that have a -Credential parameter. The first command will throw this error:
here-Object : An operator is required to compare the two specified values. Include a valid operator and retry.
t line:1 char:15
Get-Command | ? parameters.containskey('Credential') | sort name

           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

• CategoryInfo : InvalidArgument: (:) [Where-Object], PSArgumentException


• FullyQualifiedErrorId : OperatorNotSpecified,Microsoft.PowerShell.Commands.WhereObjectCommand

Internal BugId: 3047

Votes from Connect: 41

Original Date Submitted: 9/8/2011 8:47:16 PM

Description:

Contact Information
Handle: HalR
Site Name: PowerShell
Feedback ID: 687640

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

Problem Description:
Something similar to the Get-Parameter function published on PoshCode (see http://poshcode.org/?lang=&q=get-parameter for latest version) needs to be included in PowerShell. The purpose of Get-Parameter is to parse the output of a cmdlet or function's CommandInfo returned from Get-Command, and turn it into a more useful format by which the end user can discover more about:
- what paraemtersets exist?
- what triggers a parameterset? (i.e. which are mandatory)
- what pipeline input does a cmdlet/function accept?

And more. Some of these are questions that you can discern from the help file only after reading pages and pages of data (Get-Help -Full) and basically doing much more work in your head than is necessary. Some of these questions cannot be adequately answered in the help at all and must be discovered by experimentation if the help author omitted input type data.

The answers are all in the paraameterset data. IMHO the Get-Parameter function is more useful than Get-Help because while you will refer to the help the first few times when using a new cmdlet, once you have the basics down, Get-Parameter is a more quickly digested tool and something that you will end up using on a daily basis.

More details can be found on this blog post: http://halr9000.com/article/507

P.S. I like 'gpm' as a built-in alias.

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

Repro Steps:
Expected Results:
Love this:

PS > gpm Get-EventLog

ParameterSet: LogName

Name Type IsMandatory Pipeline

LogName String True False
ComputerName String[] False False
Newest Int32 False False
InstanceId Int64[] False False
Index Int32[] False False
EntryType String[] False False
Source String[] False False
Message String False False
AsBaseObject SwitchParameter False False

ParameterSet: List

Name Type IsMandatory Pipeline

ComputerName String[] False False
List SwitchParameter False False
AsString SwitchParameter False False

Internal BugId: 3010

Votes from Connect: 56

Original Date Submitted: 4/12/2011 2:47:03 PM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 659747

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

Problem Description:
PowerShell has an automatic variable, $pwd. One of its great usage is that its value is evaluated each time you call it and you can access its members without enclosing it in parenthesis.

I would like to suggest a new automatic variable (tied variable), $Now, that returns the current date and time each time it's called.

Having $Now as a new automatic variable in PowerShell can save us extra typing, prevent enclosing get-date in parenthesis (when we need to access its members) and even save us a variable assignment to hold the current date and time, it also can be used inline in cmdlet parameters value without having to create a $date variable first.

So instead of doing:

$date = (Get-Date).MemberName

We could simply do:

$Now.MemberName

There's a post blog on the PowerShell team blog, by Ibrahim Abdul Rahim (http://blogs.msdn.com/b/powershell/archive/2009/03/26/tied-variables-in-powershell.aspx), that explains how to do it, and also an extended version by Lee Holmes (http://www.leeholmes.com/blog/2009/03/26/more-tied-variables-in-powershell)

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

Repro Steps:
Expected Results:

Internal BugId: 2900

Votes from Connect: 13

Original Date Submitted: 12/27/2008 11:39:54 PM

Description:

Contact Information
Handle: tfl
Site Name: PowerShell
Feedback ID: 389767

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

Problem Description:
I think the new auto-help stuff is fantastic. But it's a tad buggy and inconsistent.

To demonstrate this, I've created a simle advanced function file (get-autohelp.ps1) attached. You will need to save this file then run get-help against it to see the errors I note.

Here are the issues:

1. You can not specify a .NAME section in auto-help. If you do, then the output returned by get-help is heaviliy truncated. You should enable the developer to specify a name section, with Get-Help then supplementing this with the file name that the script lived in.




2. Two sections change name from script file to output by Get-Help. The ".DESCRIPTIION" section becomes "Detailed Description" in get-help output. And .LINK befomes "RELATED LINKS. This is inconsistent. Either make Get-Help produce the section names in the file, or change what sections you can specify in the file to match what get-help produces.




3. .LINK links are shown in basic get-help output, and with -FULL, but not -Detailed. This is inconsistent - anything shown in basic output should be shown with -full or -detailed.




4. It's not clear how to use .COMPONENT, .ROLE and .FUNCTIONALITY sections. These do not appear to be output in any use of get-help. If nothing else, there needs to be more details on these sections.

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

Repro Steps:
1. Take Get-AutoHelp.ps1 from bug report and save it.
2. To see issue 1, add a section:
.NAME

FOO

before line 2 in attached script. Run Get-Help, Get-Help -full, Get-Help -Detailed against the script, then do it again with these lines removed.

1. Run Get-Help, Get-Help -full, Get-Help-Detailed to see the first three issues.




2. Run get-help -role *, get-help-component * to see issue

Expected Results:
1. Ability to specify a name
2. Consistency of section names to get-help output
3. Ability to use .COMPONENT, .ROLE, and .FUNCTIONALITY sections

Internal BugId: 1838