A rule to warn overwriting of built-in PowerShell cmdlets

[TylerLeonhardt]

Summary of the new feature

See the issue we faced over in PSES:
PowerShell/PowerShellEditorServices#686

MS Dynamics CRM redefines Set-Content which totally broke PSES.

We should have a rule that detects the overwriting/redefining of important built-in cmdlets to prevent these breaks from happening in future module development.

[rjmholt]

From my now-closed issue:

Summary of the new feature

Followup from PowerShell/PowerShellEditorServices#686 (review).

Some users have had problems starting PSES because other modules override core cmdlets (in the above case, Set-Content is redefined...). We can't prevent it, but ideally module authors should get a stern warning!

In user story terms:

As a module/script author, I want to be warned when I'm redefining core cmdlets
so that my module/script is less likely to interfere with/break other PowerShell modules when installed.

Proposed technical implementation details

The rule should probably lazily cache all the cmdlet names in the following core modules:

• Microsoft.PowerShell.Core
• Microsoft.PowerShell.Management
• Microsoft.PowerShell.Utility
• PSReadLine
• Microsoft.PowerShell.Diagnostics
• Microsoft.PowerShell.Host
• Microsoft.PowerShell.Security
• Microsoft.PowerShell.Archive
• Microsoft.WSMan.Management
• PowerShellGet?

An ideal implementation probably has a default list of modules, which can be changed or added to.

The simplest way to do this is to read the module manifest or run Get-Module <module> | Select-Object ExportedCommands.

In the case where an author wants to prevent redefining cmdlets in a module they don't have installed at analysis time, I'm not entirely sure what the correct solution is, but can't imagine the problem being insoluble.

What is the latest version of PSScriptAnalyzer at the point of writing

1.17.1

[rjmholt]

Update: I think the best solution for implementing this is:

Get-Command -Module <module>

Unlike Get-Module <module> | Select-Object ExportedCommands, this works with Microsoft.PowerShell.Core...

[bergmeister]

PSSA already ships with files that contain cmdlet names (and their parameters) for PowerShell version 3, 4, 5 and 6.0.2. At the moment those files are used for the UseCompatibleCmdlets rule to warn on usage of cmdlets that are not available on different PowerShell versions. In a similar fashion you could use those cmdlet names for this new rule. Let me know if you need more details for implementing this rule.