1

I am working on a powershell module that has many cmdlets. I've been asked if we can add something to the cmdlets to prevent namespace collisions between modules. One thing that has been proposed if we could add something before the verb. ex. dotnet build . Basically is it possible to put something that would be customname add-newitem? I've looked into qualified module names, but that is a bit clunky.

I've also looked into the manifest file defaultcommandprefix, and that does work, but the prefix is still after the verb.

mituw16
  • 5,126
  • 3
  • 23
  • 48

2 Answers2

1

it's not the same, when you use dotnet build you run dotnet.exe with build argument.

I don't think you can do this in powershell (just take a look at the microsoft powershell command for azure or o365 and you will see very long command name to avoid that).

you still can use a name like :

customname-add-newitem

but the best should be :

add-newCustomNameItem

Eldrad95
  • 35
  • 5
  • That's kind of what I figured based on everything I've found so far. Thanks! Do you know how to do something like `customnane-add-newitem` ? I haven't been able to figure out how to add anything before the verb. Your second suggestion may be what I fall back to – mituw16 Jul 28 '22 at 15:05
  • 1
    PowerShell "gets annoyed" if you don't conform to the standard VERB-NOUN naming for cmdlets or scriptlets/script cmdlets/advanced functions. What we do in our enterprise for custom organization-specific scriptlets is prefix the noun with an organization indicator, e.g., `Get-OrganizationWorkstationPrinterConnections`. – Jeff Zeitlin Jul 28 '22 at 15:14
  • 1
    `Add-NewItem` is not a recommended cmdlet name, it is either `Add-Item` or `New-Item`, see: [Approved Verbs for PowerShell Commands](https://learn.microsoft.com/powershell/scripting/developer/cmdlet/approved-verbs-for-windows-powershell-commands) – iRon Jul 28 '22 at 15:51
  • @iRon sure, that was just a psuedo example. our cmdlets are properly named in the solution. thanks! – mituw16 Jul 28 '22 at 17:45
1

Each PowerShell cmdlet can be address by its friendly name, e.g. Get-Item (or an alias, like gi in this case) or by its full qualified name which is basically: <source>\<name>.

Get-Command Get-Item

CommandType     Name                  Version    Source
-----------     ----                  -------    ------
Cmdlet          Get-Item              7.0.0.0    Microsoft.PowerShell.Management

Meaning you can also address the specific cmdlet like this:

Microsoft.PowerShell.Management\Get-Item -Path .\Test

For custom module the source is the module name, e.g.:

Install-Module -Name JoinModule

Get-Command Join-Object

CommandType     Name                  Version    Source
-----------     ----                  -------    ------
Function        Join-Object           3.7.2      JoinModule

JoinObject\Join-Object ...

This basically means that there shouldn't be any need to manually prefix cmdlets with module (or customer) names. Besides there are clear verb-noun naming recommendations that even define a difference between e.g. New-Item and Add-Item. Nevertheless, if you want to be specific on an identity, the naming convention often used is: <verb>-<identity><noun>, e.g. Get-ADUser or even Get-AzureADUser.

iRon
  • 20,463
  • 10
  • 53
  • 79
  • Your answer is basically what I thought to be true. Just wanted to be sure before I tell my leads what they want isn't really possible and flys in the face of standard conventions. Thanks for taking the time to type that out! :) – mituw16 Jul 28 '22 at 17:46