New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Session-global module caching is at odds with ScriptsToProcess feature and scoped unloading of modules with Remove-Module #9582
Comments
Is it dup #6170? |
In part, @iSazonov, namely the |
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. |
2 similar comments
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. |
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. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
I'm starting to think "No Activity" is a terrible reason to close the issue as "completed". |
Import-Module
can be:implicitly scope-specific, if the same module is imported by different other modules
explicitly scope-specific, via
-Scope Local
(or-Scope Global
).By contrast, certain aspects of module handling are currently invariably session-global, seemingly due to behind-the-scenes session-global module caching:
The
ScriptsToProcess
module manifest key is only honored once per session, namely in whatever scope happens to import the module first.Remove-Module
- which doesn't have a-Scope
parameter - session-globally unloads a module, so that different scopes that had imported the module scope-locally later cannot unload that module anymore, which means that all its exports linger.Steps to reproduce
Expected behavior
All tests should pass.
Actual behavior
The 1st test fails, because the 2nd Import-Module call fails to dot-source the ScriptsToProcess script.
2nd test: The 2nd Remove-Module call fails, because the previous
Remove-Module
call in a different scope unloaded the module globally.Environment data
The text was updated successfully, but these errors were encountered: