I am trying to update Pester on Windows 2016 to 4.x because the preshipped Pester 3.4.0 emits a note about the depreciation of the -quiet switch when I use the quiet switch. This get's scooped into stdout when executing via AWS SSM remote commands. Version 3.x complains it does not understand "-Show None".

I want to update to 4.x - in which I ran into all the problems documented here: https://github.com/OneGet/oneget/issues/215

But ended up with "Install-module pester -force -SkipPublisherCheck.

So far so bad, but when I go to remove the 3.4.0 version (with admin rights) from: 'c:\program files\windowspowershell\modules\pester\3.4.0' I get errors because only TrustedInstaller has permissions.

If this scenario wasn't horrible enough, putting preinstalled modules under Windows Resource Protection really throws it over the top.

Could someone please make sure that preinstalled modules can be *replaced* cleanly? Or don't preinstall them?

I've tried several ways to capture the PowerShell documentation into a single PDF file which I find much more convenient instead of clicking around a Microsoft site. Acrobat just locks up. I've never seen it behave this way before.

It places PowerShell out of reach for those of us trying to learn new tools.

Please try it yourself. Acrobat XI Pro.
- Use the browser plugin "create PDF from webpage"
- Or start with Acrobat "create PDF"
- Or Browser / Save as html complete

Print to PDF is inadequate because webpage links are missing and on the PowerShell pages, the side-bar links are missing.
- Acrobat Printer
- Microsoft Print to PDF

In Azure Automation DSC the whole MOF file gets encrypted without the need to manually issue certificates for every node and then to collect the public keys.

From Azure documentation:
"Keeping credentials secure in node configurations (MOF configuration documents) requires encrypting the credentials in the node configuration MOF file. Azure Automation takes this one step further and encrypts the entire MOF file."

This extremely useful feature sould also be implemented in the on-premises DSC pull server. Especially because the needed functionality must alread be in the WMF 5 as nothing more than WMF 5 is needed to use the Azure Automation DSC service.

This would be huge improvment for the DSC pull server.

Thx!

The PowerShell gallery should allow users to create "lists" of modules (think of it as an Amazon wish list).

A user could create a "favorites" list and add modules and scripts to it to keep track of their favorites over time (maybe even "subscribe" to notifications of new releases of things on the list).

A user could also create a "user management modules" list or a "stretching PowerShell's limits" list or a "should have been in the box" list, or a "things I use in my prompt" list ...

But most importantly, users should be able to SHARE those lists, and other users should be able to download and install a list (maybe something like Install-Module -ListName MyPrompt -Author Jaykul).

Additionally, if you could show a count of how many users have added the module to at least one list, and a count of how many lists it's on, these would potentially be useful non-download metrics for popularity.

It would be awesome if there was a way to get additional sorting metrics for the gallery (downloads in the last week, vs. all-time, perhaps), and this would give you several possible additional metrics (users, lists, and the "all time" vs "last month" or "last week" to get hotness).

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.

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.

It would be nice to be able to delete a module that hasn't been downloaded yet and is unlisted. I made a mistake in publishing a module which I unlisted before anyone downloaded it. There is no benefit to me or anyone having it remain in the gallery.

None of the follwing published reasons for disallowing deletions apply:

1. Other items may depend on that item. Those items might not necessarily be in this gallery.
2. Ensures that folks using items without committing the same will not be broken.
3. Helps ensure that important community owned items are not mass deleted.

For 1 - nothing depends on this, if someone does download it they're being facetious and just going to be wasting their time.

For 2 - Not sure what this means, but if it has something to do with preventing resubmissions of the same version number, that would actually be good for me since no one has downloaded it yet anyway and I could just publish that version without having to increment it.

For 3 - It's only important if it's been downloaded, but it hasn't yet, so let me delete it.

It would be very useful if Out-Gridview provided a build in display of the number of objects in the grid. This could be in a status bar at the bottom or at the top along with the Add Criteria button.

This would update as the filters are applied. It would also be nice if the selected items had a count as well.

It would be especially useful with -passthru as you could have an estimate on the number of objects being passed to the next cmdlet in the pipeline.

You can come up with the count by using measure-object, but that number only comes after committing to pass objects back through the pipeline.

I often pass things from the clipboard or csv files to cmdlets and it would be nice to know how many are going through at execution time.

Love PowerShell!