Powershell: RequiredModules manifest property stopped working recently (noticed in daily build)

[bergmeister]

This issue started only in the last few days using the daily build and does not happen with 6.1 or 6.1-preview.
Calling Import-Module on a module that declares RequiredModules = @('C:\full\path\to\manifest.psd1'), causes loading of it to fail. A specific example of such a manifest is here but even if I change it to just one dependent module with a full path, it still happens, therefore I think the issue is generic to any manifest. with RequiredModules

Steps to reproduce

Import-Module $PathToManifestThatDeclaresRequiredModules

Expected behavior

Imports dependent modules

Actual behavior

Throws because it fails to import dependent modules.

Import-Module : The required module 'C:\Users\cberg\git\posh-profile\source\dotnetCli\dotnetCli.psd1' is not loaded. Load the module or remove the module from 'RequiredModules' in the file 'C:\Users\cberg\git\posh-profile\source\posh-profile.psd1'.

Loading the dependent module works fine but an Import-Module of the main module fails again with the same error

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.2.0-preview.864
PSEdition                      Core
GitCommitId                    6.2.0-preview.864
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

@TravisEz13 @rjmholt Could you please look the issue?

[rjmholt]

The error occurs here:
https://github.com/PowerShell/PowerShell/blob/4118fd2829cb1a0a64005bd5b84e08ca7ea354e2/src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs#L3717

After my changes there, the assumption is made that the module name for a module after it's loaded is the same as if we find it. However, we are given the module path and compare it to just the name.

I'll prepare a PR and some testing around this.

@adityapatwardhan, @TravisEz13 hopefully I can have a fix for you within the day.

[rjmholt]

I'm currently confused by the fact that the module name is obtained the same way as it always was:
https://github.com/PowerShell/PowerShell/blob/e888e5109785871af09df22d30f87bc8b375502c/src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs#L3661-L3667

And the comparison logic is the same too.

So I need to work out why we are now getting a path rather than a name.

[rjmholt]

Ok, so it turns out we've always failed that first check (even if the module is already loaded, we still end up calling Get-Module -ListAvailable).

The fix lay in not checking the name when we actually load the required module.

I have a quick fix available in the PR linked above.

However, with more time I'd like to write out tests for this and then fix it properly.

[TravisEz13]

@rjmholt when was this introduced? Can you include a link to the commit?

[rjmholt]

https://github.com/PowerShell/PowerShell/commit/5d06fba36662c17df32805f73d174f514e822191

[TravisEz13]

Thanks

[bergmeister]

@rjmholt Thanks, I appreciate your hard work in the last days, I can confirm that your PR #8218 has fixed the issue for me in the latest nightly build (6.2.0-preview.876)

[rjmholt]

@bergmeister Happy to help -- I broke it, so I'm glad I was able to fix it. Thanks for letting me know it's working