Wanted to update this thread with the current status and an approach that will allow uninstalling easily.

At this time we are not planning on implementing this feature. There are a large number of error conditions that can arise during an installation, and the general PS approach is not to add large numbers of parameters to support what are actually separate actions. In this case, the install and uninstall are separate.

The following command can be used (without the ending -Whatif) to clean up older versions of installed modules:
$Latest = Get-InstalledModule (modulename); Get-InstalledModule (modulename) -AllVersions | ? {$_.Version -ne $Latest.Version} | Uninstall-Module -WhatIf

Per the discussion, this seems to be operating properly. If we missed something, please add additional information to the item so we can understand it better.

After trying to make this work for some time, we have decided that we really can’t support this in an ongoing basis.

There was a DSC configuration created that set up a copy of the (then) current PS Gallery. The problem we encountered with it is the ongoing maintenance cost of keeping the published version in synch with our changes, particularly when you realize that the Gallery is a multi-tier app.

As a result, we have to decline this request, and instead ask users to leverage a NuGet-based repo if they want one.

Hi Jeff,

You’re setting $b to a formatting object because you’re passing to Format-Table in the assignment.

Drop the ft from your $b = … and $b.count and $b | gm should be accurate.

Thanks,
Joey

This has been suggested previously, and unfortunately, is not easy as implied by this suggestion.

Managing group membership and associating that with individual items requires a great deal of plumbing. In addition, the PowerShell Gallery browse and acquisition (install, save, update cmdlets) operate anonymously.

While these things could be done, they are not part of the strategic direction for the PowerShell Gallery at this time.

Given what I know about the scoping of trap statements, this looks like “by design” behavior to me. More on that:

about_Trap: https://msdn.microsoft.com/en-us/powershell/reference/5.0/microsoft.powershell.core/about/about_trap#trapping-errors-and-scope
Great discussion on Trap vs. Try/Catch: https://powershell.org/2013/06/11/powershell-great-debate-error-trapping/

For your immediate problem, I think you could just make a “ProxyThrow” function that defines it’s own scoped Trap and Throws.

First, thanks for asking, we really do appreciate the feedback.
We have investigated doing this before, and it turns out to be complex.

While it’s been done, it’s not common for a reason. Some of the issues involve creating a service that is effectively a sandbox designed to run a huge variety of cmdlets, while ensuring that it cannot become a DOS attack vector for the service as a whole.

Rather than leave the request open, we are marking it as “declined” for now.

As it turns out, this is really difficult and the likelihood of delivering something that would work is not high.

The biggest issue with providing the in-box modules via the Gallery is that the PowerShell modules you are interested in require other code elements that ship as part of the Windows versions the PowerShell code ships in. If you don’t have a matching set, the PowerShell cmdlets can’t work.

Moving forward, many teams are considering using the PowerShell Gallery as their primary path to providing PowerShell modules. That will require changes to how they develop the PS code, and make this easier.

However, repackaging existing in-box modules & delivering them via the PS Gallery will not be successful.

Check out this documentation on Automatic Variables: https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.core/about/about_automatic_variables

$? is designed to output whether the last operation was successful or not ($true/$false):
“Contains the execution status of the last operation. It contains TRUE if the last operation succeeded and FALSE if it failed.”

$LASTEXITCODE “Contains the exit code of the last Windows-based program that was run.” This only applies to native binaries. Try this:

PS C:\Users\jaiello> clip

INFO: Type “CLIP /?” for usage.
PS C:\Users\jaiello> $LASTEXITCODE
0
PS C:\Users\jaiello> clip foo
ERROR: Invalid argument/option – ‘foo’.
Type “CLIP /?” for usage.
PS C:\Users\jaiello> $LASTEXITCODE
1

If you still feel like these don’t meet your needs, please file an issue at https://github.com/powershell/powershell/issues

I can’t repro this on my personal machine (even with the Taskbar moved to the top). Every entrypoint/shortcut for PowerShell (or cmd.exe for that matter) have their own window/console properties that get saved for that entrypoint/shortcut. I recommend that you right-click the PowerShell icon in the console title bar, select Properties, Layout, and fiddle with the Window Position (you probably want to uncheck “Let System Position Window”.

Thanks,
Joey

As described, this seems to us to be problematic to implement in the core cmdlets for security reasons.
However, there may be workarounds available. Please contact keithb@microsoft.com if you wish to follow up.

As explained in the attached GitHub Issue, this is by design

That behavior appears to “by design” to me. As far as the parser can tell, your `;` is part of the comment you started with `#`. In addition to the workaround you posted yourself, you could do a after (or before) the `;`, and the parser would terminate the comment via a newline.

Was this behavior different before the build you referenced in your title?

I’d love to, but given that we’ve already been burned by this whole “aliases masking whether you’re using the native executable or the PowerShell cmdlet” business (context here: https://github.com/PowerShell/PowerShell/pull/1901), and given that there are slight behavioral differences between the two, I’m going to have to recommend that you just put it in your profile.

To give a brief example: say we add this default alias. “… | clip” starts getting used in scripts (this is why you don’t use aliases in your scripts!), and all of the sudden there’s a bunch of scripts out in the wild with different behavior, and no clear reason why unless you’re familiar with the aliases we added, and in which version.

If you feel strongly that I’m wrong, feel free to file an issue on GitHub to affect PowerShell Core 6.0: https://github.com/powershell/powershell/issues

Thanks,
Joey

Lacking the information needed, we have no choice but to close this item.

Unforunately, you do have the wrong place. You can get help with PowerShell scripting on the TechNet forums: https://social.technet.microsoft.com/Forums/windows/en-US/home?forum=winserverpowershell

This forum is strictly for bug reports and feature requests. Thanks!

Doing this from the ISE is realistically out of scope.

We are addressing this by adding the ISE to Visual Studio Code. You can find out about that project here: https://github.com/PowerShell/PowerShellEditorServices

Thanks for asking about this, we do need to provide the information as it’s important for publishers.

Turns out that this is something you can currently do, using this script:
Find-Module | Where-Object { $.Dependencies | Where-Object { $.Name -eq ’Pester’} }

We are updating the FAQ documentation to include this info.
If we get a lot of people requesting this to be built-in for find-X, we’ll review this again.

As 响叮咚 said, ‘mm’ is used for minutes, not month. Use MM instead, and you should be good :)