Stop referencing Microsoft.PowerShell.Security when the core snapin is used

[daxian-dbw]

PR Summary

This is a follow-up change of #16355.
The strong reference to Microsoft.PowerShell.Security is not needed anymore after merging #16355.

There are whitespace only changes in the PR, so it's easier to review by ignoring the whitespaces:
https://github.com/PowerShell/PowerShell/pull/17771/files?w=1

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed

[iSazonov]

It seems there are more dependences on the module :-) Easy to remove.

[daxian-dbw]

/cc @iSazonov @SteveL-MSFT @JamesWTruher

It turns out it's sort-of intentional to load Microsoft.PowerShell.Security.dll eagerly.
After this change (and #16355), loading of the Microsoft.PowerShell.Security module fails with the following error (see the same failure in CI):

PS:1> Import-Module Microsoft.PowerShell.Security
Import-Module: The following error occurred while loading the extended type data file:
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(19) : Error in type "System.Security.AccessControl.ObjectSecurity": The "Type" node must have "Members", "TypeConverters", or "TypeAdapters".
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(52) : Error: CodeProperty should use a getter or setter method.
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(53) : Error: Unable to find type [Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase].
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(45) : Error: CodeProperty should use a getter or setter method.
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(46) : Error: Unable to find type [Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase].
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(38) : Error: CodeProperty should use a getter or setter method.
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(39) : Error: Unable to find type [Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase].
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(31) : Error: CodeProperty should use a getter or setter method.
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(32) : Error: Unable to find type [Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase].
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(24) : Error: CodeProperty should use a getter or setter method.
, C:\arena\Modules\Microsoft.PowerShell.Security\Security.types.ps1xml(25) : Error: Unable to find type [Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase].

This is because the processing of type.ps1xml and format.ps1xml happens before loading NestedModules, and hence when the type.ps1xml references a type from the nested module, the type cannot be resolved when processing the type.ps1xml.

The use-nested-module.zip is a simple repro of this behavior. Unzip it, and run import-Module <path-to>\conflict will demonstrate the problem.

However, it will work fine when using RootModule = 'conflict.dll' instead of NestedModules = @('conflict.dll') in the module manifest. I believe the root module is specially handled with eager loading. (use-root-module.zip)

Both PowerShell 7.0 and 7.2 has the same behavior. But on Windows PowerShell, both use-nested-module and use-root-module will fail to process the type.ps1xml file.

---

QUESTION: Changing the loading order of nested module would be a non-trivial work which is quite risky. Given that, shall we revert #16355?

[iSazonov]

@daxian-dbw Your question raise more questions:

1. Is PS team strategy to decouple built-in modules actual or it was deprecated?
2. Should we keep circular dependencies Circular dependency at runtime between System.Management.Automation and Microsoft.PowerShell.Security #14095?
3. Why do built-in modules use NestedModules instead of RootModule in psd1? Is it a bug?

[daxian-dbw]

A workaround is to add RequiredAssemblies = "Microsoft.PowerShell.Security.dll" in addition to the NestedModules. Required assemblies are always loaded before processing type/format files, and this allows the module to remain a manifest module.

I have pushed a commit with that change. Although it looks weirdly redundant, I think it should be acceptable.

> Why do built-in modules use NestedModules instead of RootModule in psd1? Is it a bug?

I don't think it's a bug or oversight. My guess is:

1. Declaring the security.dll as a root module doesn't solve the problem in Widows PowerShell, as I mentioned above:

   But on Windows PowerShell, both use-nested-module and use-root-module will fail to process the type.ps1xml file.

2. Back in Windows PowerShell time, some built-in modules contain both .psm1 and .dll nested modules, and making the parent module a manifest module makes perfect sense.

[iSazonov]

Great!

[SteveL-MSFT]

The workaround with RequiredAssemblies is low risk and I think this is a change we should have to decouple them

[ghost]

🎉v7.3.0-preview.7 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes