Describe the bug
After the dependency-isolation changes introduced in #3789 , removing and re-importing Microsoft.Graph.Authentication in the same PowerShell 7+ session can leave dependency resolution broken.
Actual Behavior
Re-import or subsequent command execution can fail when resolving Microsoft.Graph.Authentication.Core.
Root Cause
Removing the module calls GraphLoadContextInitializer.Shutdown(), which unregisters the default-context resolver but retains the non-collectible private load context.
On re-import, Initialize() returns immediately because that context already exists, leaving the resolver unregistered. The binary module’s static constructor also does not run again.
Proposed Fix
Track resolver registration separately from context creation. Reuse the existing private context and re-register the resolver on subsequent imports.
Add regression coverage for importing, removing, and re-importing the module within one PowerShell process, followed by command execution and load-context assertions.
Fixed by PR: #3804
Expected behavior
The module can be removed and re-imported successfully, and its commands continue working with dependencies loaded into the private assembly load context.
How to reproduce
Using a build containing #3789 (v2.41):
Import-Module Microsoft.Graph.Authentication
Remove-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Authentication
SDK Version
2.41.0
Latest version known to work for scenario above?
No response
Known Workarounds
No response
Debug output
Click to expand log
```
</details>
### Configuration
_No response_
### Other information
_No response_
Describe the bug
After the dependency-isolation changes introduced in #3789 , removing and re-importing
Microsoft.Graph.Authenticationin the same PowerShell 7+ session can leave dependency resolution broken.Actual Behavior
Re-import or subsequent command execution can fail when resolving
Microsoft.Graph.Authentication.Core.Root Cause
Removing the module calls
GraphLoadContextInitializer.Shutdown(), which unregisters the default-context resolver but retains the non-collectible private load context.On re-import,
Initialize()returns immediately because that context already exists, leaving the resolver unregistered. The binary module’s static constructor also does not run again.Proposed Fix
Track resolver registration separately from context creation. Reuse the existing private context and re-register the resolver on subsequent imports.
Add regression coverage for importing, removing, and re-importing the module within one PowerShell process, followed by command execution and load-context assertions.
Fixed by PR: #3804
Expected behavior
The module can be removed and re-imported successfully, and its commands continue working with dependencies loaded into the private assembly load context.
How to reproduce
Using a build containing #3789 (v2.41):
SDK Version
2.41.0
Latest version known to work for scenario above?
No response
Known Workarounds
No response
Debug output
Click to expand log
```