Specifying all three of Cmdlets/Aliases/FunctionsToExport prevents export of DSC Resources

[alx9r]

This came up while trying to apply the proactive importing of required modules described in #12036 (comment) to my repo of PowerShell 5.1 modules. (There is also some background in #12014.) I have a number of modules that export DSC Resources and use the public SqlServer module. For this discussion and the repro below, I am referring to such a module as m and the resource it exports as r.

Without importing the SqlServer module inside m, command resolution for SqlServer occurs in the global scope. Resolution in the global scope can lead to a name inside module m resolving to a command in an unrelated module. That problem is demonstrated in #12014 and #12036.

In order to force command resolution to the commands exported by the SqlServer module to occur inside module m the SqlServer module is imported inside the user module. This is mocked by the line # Import-Module SqlServer below. The effect of this import on name resolution is demonstrated here. With that import in place command resolution occurs inside module m instead of in the global scope. That much is good.

Introducing Import-Module SqlServer inside module m has the side-effect of m exporting all of the commands that SqlServer exports. The customary way to manage this is to specify Cmdlets/Aliases/FunctionsToExport in m's module manifest. Specifying all three, however, has the side-effect of preventing DSC resources from being exported from m. So I'm left with three undesirable options, it seems:

1. Permit names to resolve to commands in the global scope, thereby not solving the problems in Get-Item for files outputs PSObject instead of FileSystemInfo after Get-WmiObject #12014 and Release Process for v6.x.x #12035
2. Allow module m to export commands from SqlServer thereby polluting the namespace with those numerous commands wherever module m is used.
3. Don't export DSC resources from m.

---

I have the following questions:

1. Is this a bug? Or is this in line with the design intent?
2. Is there some other way to restrict the export of commands without also inadvertently preventing the export of DSC resources?

Steps to reproduce

Create the following well-formed module in $Env:PSModulePath:

# m.psd1
@{
    ModuleVersion        = '0.1.0'
    RootModule           = 'm.psm1'
    DscResourcesToExport = 'r'
    CmdletsToExport   = @() # Commenting out any 
    AliasesToExport   = @() # of these lines results
    FunctionsToExport = @() # in the expected behavior.
}

# m.psm1

# Import-Module SqlServer

[DscResource()]
class r
{
    [DscProperty(Key)]
    [string]
    $Key

    Set() {}
    [bool] Test(){ return $true }
    [r] Get(){ return $this }
}

Invoke the following command:

Import-Module m; Get-DscResource r m

Expected behavior

Name Module Properties
---- ------ ----------
r    m      {Key, DependsOn, PsDscRunAsCredential}

Actual behavior

Write-Error: C:\program files\powershell\7\Modules\PSDesiredStateConfiguration\PSDesiredStateConfiguration.psm1:4035
Line |
4035 |              CheckResourceFound $Name $Resources
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The term 'r' is not recognized as the name of a Resource.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[General-Chaos]

I have also run into this today for module 'JeaDSC' version 0.6.5 which has embedded dsc class resources, this behavior is still present in 7.1.0-preview.5 (for mof compilation in this case) , both on windows and Ubuntu 18.04. Setting 'Aliasestoexport' to '*' also prevents this happening, but that isn't an option for external modules.

JeaDsc: https://github.com/dsccommunity/JeaDsc

GitHub

dsccommunity/JeaDsc

Just Enough Administration. Contribute to dsccommunity/JeaDsc development by creating an account on GitHub.

[ghost]

I have hit this on a module I'm developing. Fortunately for me, the module in question only provides DSC resources, so I could easily work around it, but it was still extremely confusing.

[anmenaga]

This is a bug in Get-Module -ListAvailable -Name m that is used by DSC, where there is a code path that returns the collected module information before the ExportedDscResources is set for the module.

[ghost]

I just hit this issue again and spent a bunch of time stepping through a debug build of PS7.2.6. The exact trigger conditions are if none of CmdletsToExport, FunctionsToExport, or AliasesToExport uses a wildcard; all three default to '*' if not specified, which prevents triggering the bug. My suggestion would be to copy the SetDeclaredDscResources() call from line 3503 (of ModuleCmdletBase.cs) into the if block starting on line 2796 (line numbers as of tag v7.2.6), though I don't know if that method has more complex requirements.

It may be a good idea to look through the rest of the skipped code for other, similar issues.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.