Assert-Module issue with backwards compatibility

[mgreenegit]

Problem description

In Assert-Module, there is a check to see if a module is available and if not, throw an exception. I've run into an issue trying to run community resources in Pwsh 7.x, when the resource is using assert-module to verify a PowerShell module that is expected to be available in Windows PowerShell 5.1. The workaround looks to be -skipeditioncheck, but we would need to test to see if that breaks any other part of the workflow for dscresource.common.

Reference:

DscResource.Common/source/Public/Assert-Module.ps1

Line 67 in b172255

if (-not (Get-Module -Name $ModuleName -ListAvailable))

To see the difference, try running these examples in Pwsh 7.x.
$p = Get-Module -listavailable
$p.count

$s = Get-Module -listavailable -skipeditioncheck
$s.count

Verbose logs

NA

How to reproduce

$p = Get-Module -listavailable
$p.count

$s = Get-Module -listavailable -skipeditioncheck
$s.count

Expected behavior

Assert-Module should identify modules from Windows PowerShell 5.1 even when hosted in Pwsh 7.x, due to implicit remoting.

Current behavior

Implicit remoting is not invoked. Normally it would happen at import, but the import is not called because Get-Module -listavailable does not find it, so Assert-Module throws an exception.

Suggested solution

Test with -skipeditioncheck to verify whether it resolves the issue or if any regressions are created.

Operating system the target node is running

NA

PowerShell version and build the target node is running

7.x

Module version used

NA

[johlju]

The parameter SkipEditionCheck does not exist in 5.1, but if we only pass parameter SkipEditionCheck when Assert-Module is not run in Windows PowerShell then it wouldn't break anything I think.