When you log into the PowerShell Gallery, if you click on your username you're taken to your account page. This account page contains your API Key in plain text, visible by default. Since the API Key is the key that is used to publish your modules/scripts to the Gallery, the UI should hide these "keys to the kingdom" by default with an option in the UI to show the Key. I have seen many demos of the Gallery where the API Key is shown when it simply shouldn't be shown at all, simply because the person delivering the demo clicked on their user id. As someone who delivers demos in front of large audiences that are often recorded, I would appreciate if you would make my life easier by simply hiding the key unless I specifically want to show it in the UI.

For the core modules in PowerShell 5.0, Get-Help -Online opens the help for PowerShell 4.0, not for PowerShell 5.0. Typically, -online gets help for the latest version of the module by default.

For example: Get-Help Import-Module -Online
...opens "https://technet.microsoft.com/library/af616c24-e122-4098-930e-1e3ea2080ade(v=wps.630).aspx", the 4.0 version of help.

That's because the first related link in the XML help topic has the FWLink for the 4.0 topic.

I suspect this is a bug caused by an incomplete understanding of how -Online works. The tool (or person?) that was supposed to update the links for 5.0 didn't know how it worked and updated only the HelpUri attribute.

The URI for online help can be added in one of two places:
-- First related link of cmdlet/function help
-- HelpUri attribute of the cmdlet

When both are populated, the first related link takes precedence.

For core cmdlets, the URI in the first related link is the URI to the PowerShell 4.0 version of the help topic. For example:

(Get-Help Import-Module).relatedLinks.navigationlink[0].uri
http://go.microsoft.com/fwlink/p/?linkid=289591

The link to the Import-Module help for PowerShell 5.0 is the value of the HelpUri attribute of the cmdlet.

(gcm Import-Module).helpuri
http://go.microsoft.com/fwlink/?LinkID=141553

We should fix this and make sure that the tools for 6.0 do it right.

Upgraded from WMF 4.0 to WMF 5.0 on Windows 7 SP1 x64 with .NET 4.6.1 and can't get NuGet/OneGet etc. to work at all. Already tried uninstall of WMF 5.0 and reinstall to no avail.

PS T:> Install-PackageProvider -Name NuGet -ForceBootstrap
Install-PackageProvider : Unable to find repository with SourceLocation ''. Please use Get-PSRepository to see all
available repositories.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -ForceBootstrap
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac

kageProvider], Exception

+ FullyQualifiedErrorId : RegisterPackageSourceRequired,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPack

ageProvider

PS T:> Get-PSRepository
PackageManagement\Get-PackageSource : Unable to find module providers (PowerShellGet).
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:3544 char:31
+ ... ckageSources = PackageManagement\Get-PackageSource @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...etPackageSource:GetPackageSource) [Get-PackageSource

], Exception

+ FullyQualifiedErrorId : UnknownProviders,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPackageSource

PS T:> Get-PackageProvider
PS T:> Get-PackageProvider -ListAvailable
PS T:> dir "$env:LOCALAPPDATA\Microsoft\Windows\PowerShell\PowerShellGet"
PS T:> [environment]::OSVersion.Version

Major Minor Build Revision

6 1 7601 65536

PS T:\Win\Too\admin\DHE> $PSVersionTable

Name Value

PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PowerShell ISE - Where are the default snippets after Win10 Upgrade?

So I've upgraded to Win10Pro 1803 17134.1, opened my trusty PowerShell ISE, pressed CTRL+J and nothing happens!? Even the Get-ISESnippet is not showing any results. I'm using the default snippets and don't have any custom snippets under my documents / PowerShell folder.

It seems to be related to OneDrive or Windows 10 update as both my Desktop and Laptop have the same problem.

According to JRV the same issue occurs on 1809 builds.

Link: https://social.technet.microsoft.com/Forums/en-US/47ded9fb-0501-4953-92cc-ef55dbf86fbe/powershell-ise-where-are-the-default-snippets-after-win10-upgrade?forum=winserverpowershell

Best Regards,
Glenn

$PSVersionTable

Name Value

PSVersion 5.1.17134.1

PSEdition Desktop

PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}

BuildVersion 10.0.17134.1

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

my "Ideas" is Powershell ISE should not crash.

https://github.com/PowerShell/PowerShell/issues/6846

teps to reproduce
Use Windows Powershell ISE on Windows Build 17134
Enter the name of any cmdlet, a dash, then press ctrl+Space.
Get-Help -[Ctrl+Space]
Expected behavior
Should show intellisense popup.
Actual behavior
Instead of an intellisense dropdown, a small dot appears.

Messagebox as follows, followed by closing:

Windows PowerShell ISE - Error

An unexpected error has occurred, and Windows PowerShell ISE must close.

OK

Running in the visual studio debugger shows two exceptions, one from Xaml (associated with the appearance of the dot) the other a NullReferenceException which appears to occur in the context of a timer.
If you break on the Xaml exception there is no nullreference exception presumably because of the loss of focus.
Environment data
OS Name Microsoft Windows 10 Pro
Version 10.0.17134 Build 17134
> $PSVersionTable

Name Value

PSVersion 5.1.17134.1

PSEdition Desktop

PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}

BuildVersion 10.0.17134.1

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

More information
Running outside the debugger, instead of the intellisense pop-up I see a tiny dot appear, then the messagebox appears.
Running ISE in the visual studio debugger I see this:
Exception thrown: 'System.ArgumentException' in WindowsBase.dll
'Assertive' is not a valid value for property 'LiveSetting'.

Exception thrown: 'System.Xaml.XamlObjectWriterException' in System.Xaml.dll
Initialization of 'Microsoft.VisualStudio.Language.Intellisense.Implementation.DefaultCompletionSetPresenter' threw an exception.
And:
Exception thrown: 'System.Xaml.XamlObjectWriterException' in System.Xaml.dll
Exception thrown: 'System.Windows.Markup.XamlParseException' in PresentationFramework.dll
Exception thrown: 'System.ArgumentException' in WindowsBase.dll
Exception thrown: 'System.Xaml.XamlObjectWriterException' in System.Xaml.dll
Exception thrown: 'System.Windows.Markup.XamlParseException' in PresentationFramework.dll
And:
Exception thrown: 'System.ComponentModel.InvalidAsynchronousStateException'

The example command given under "INVESTIGATING PIPELINE ERRORS" in the about_Pipelines help topic is incorrrect. the example situation is moving a registry entry from one key to another, in the example it's trying to move the entry "product" from the hklm:\software\mycompany\design registry key to the hklm:\software\mycompany\sales key. The second ("fixed") command at the end:

get-item -path hklm:\software\mycompany\design |

move-itemproperty -dest hklm:\software\mycompany\design -name product

should be:

get-item -path hklm:\software\mycompany\design |

move-itemproperty -dest hklm:\software\mycompany\sales -name product

I also think the source and destination seem switched or misplaced throughout that section of the topic, unrelated to the example error given for the purpose of that section (tracing an error in pipeline binding).