[1.1.0-preview] Recommendation for NestedModules?

[JustinGrote]

Now that the extension vault will run in a runspace, should I stop including it in nestedmodules in the manifest? My concern is that my module will call my internal version without awareness of the runspace context, and I need to be clear to explicity call microsoft.powershell.secretmanagement\get-secret for example.

To be more clear, I'm asking if SecretManagement should require it to be a nestedmodule, because today it won't work unless it is a nested module and may lead to the ambiguous/wrong module commands being invoked.

[PaulHigin]

Good question. Yes, SecretManagement does continue to require that the extension vault module implements the vault functions ('Get-Secret', 'Set-Secret', etc.) from within a nested module with the VaultModuleName.Extension name. So the form of the extension vault module does not change. This is mentioned in the docs, but maybe it can be made more clear.

This is to hide the extension vault functions from the user. Extension vault modules can still be imported into a user session, and the vault functions should never be exposed publicly. As an example, both Microsoft.PowerShell.SecretStore and SecretManagement.KeePass vault modules have public commands and will be loaded into the user session if the commands are invoked. So the nested module is still needed to hide the vault functions.

It is always a good idea to use fully qualified names in script, just to be sure there is no ambiguity. But a user should see only one implementation of Get-Secret when running Get-Command Get-Secret.

PS> Get-Command Get-Secret

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-Secret                                         1.1.0      Microsoft.PowerShell.SecretManagement

PS> Get-Module

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Binary     1.1.0      preview    Microsoft.PowerShell.SecretManagem… {Get-Secret, Get-SecretInfo, Get-SecretVault, Reg…
Binary     1.0.2                 Microsoft.PowerShell.SecretStore    {Get-SecretStoreConfiguration, Reset-SecretStore,…

BTW, when testing the v1.10 change for SecretManagement, I updated my copy of SecretManagement.KeePass to work with the hosting change. This is how I implemented the Unlock-KeePassSecretVault function:

function Unlock-KeePassSecretVault {
<#
    .SYNOPSIS
    Enables the entry of a master password prior to vault activities for unattended scenarios. 
    If registering a vault for the first time unattended, be sure to use the -SkipValidate parameter of Register-KeepassSecretVault
    .EXAMPLE
    Get-SecretVault 'MyKeepassVault' | Unlock-KeePassSecretVault -Password $MySecureString
    .EXAMPLE
    Unlock-KeePassSecretVault -Name 'MyKeepassVault' -Password $MySecureString
#>
    param (
        [Parameter(Mandatory)][SecureString]$Password,
        [Parameter(Mandatory,ValueFromPipelineByPropertyName)][String]$Name
    )

    Microsoft.PowerShell.SecretManagement\Unlock-SecretVault -Password $Password -Name $Name
}

[JustinGrote]

Right, that's what I'm working on, and will in fact deprecate this command to just use Unlock-SecretVault directly. There's still two sessions of the module open, so will just need to be careful in the "public" module commands to reference the secretmanagement namespace directly.