Isolate Microsoft.Graph.Authentication assembly loading

[PrzemyslawKlys]

Changes proposed in this pull request

• Load Microsoft.Graph.Authentication.dll through a named AssemblyLoadContext on PowerShell Core before importing it as a binary module.
• Register a small managed dependency resolver for that load context so async authentication paths can resolve packaged dependencies from worker threads without requiring a PowerShell runspace.
• Keep Windows PowerShell/Desktop behavior unchanged by continuing to import the binary module by path when AssemblyLoadContext is unavailable.
• Preserve the public command and alias exports from the script module wrapper without re-importing the binary module by path.
• Stop adding the authentication assemblies as generated NestedModules, because that causes PowerShell to load the DLLs before the script module can choose the load context.
• Add focused module import tests that verify the root authentication assembly and worker-thread dependency resolution stay outside AssemblyLoadContext.Default on PowerShell Core.

Why

This is intended as a narrow assembly-isolation improvement for Microsoft 365 module interop scenarios where another module has already loaded incompatible authentication dependencies in the same PowerShell process. The existing module initializer resolver can help with dependency resolution after the root binary is loaded, but it cannot prevent the root authentication assembly itself from being loaded into the default context when the manifest/import path loads the DLL first.

By letting the script module load the root binary into a custom context first, the authentication module has a chance to keep its dependency graph isolated while preserving the existing exported cmdlet surface.

Validation

• pwsh -NoProfile -File .\src\Authentication\Authentication\build-module.ps1 -Release
• pwsh -NoProfile -Command 'Invoke-Pester .\src\Authentication\Authentication\test\Microsoft.Graph.Authentication.Tests.ps1 -Output Detailed'
  • 8 tests passed, including dependency resolution from a worker thread into the isolated load context.
• Artifact import smoke test confirmed:
  • Microsoft.Graph.Authentication was not present in AssemblyLoadContext.Default
  • the active context name was Microsoft.Graph.Authentication.<hash>
  • Connect-MgGraph exported successfully
  • Connect-Graph and Invoke-MgRestMethod aliases resolved correctly
• Live Graph auth smoke on Windows PowerShell 7.6.2 with WAM:
  • Connect-MgGraph -Scopes User.Read -NoWelcome succeeded
  • Azure.Identity, Azure.Identity.Broker, Microsoft.Identity.Client, Microsoft.Identity.Client.Broker, and Microsoft.Identity.Client.Extensions.Msal loaded in the Graph authentication ALC rather than default context.
• Live Exchange-first interop smoke:
  • Import-Module ExchangeOnlineManagement; Connect-ExchangeOnline loaded Exchange MSAL/Broker assemblies in default context.
  • Importing the PR-built Microsoft.Graph.Authentication artifact and running Connect-MgGraph -Scopes User.Read -NoWelcome then succeeded.
  • Graph loaded its own MSAL/Broker/Azure.Identity assemblies in the Graph authentication ALC while Exchange assemblies remained in default context.
• git diff --check

Other links

• Related to Implement proper assembly isolation to play nice with vscode-powershell #2978
• Related to Connect-MgGraph fails after Connect-ExchangeOnline #3394
• Related to ExchangeOnlineManagement and Microsoft.Graph PowerShell modules are mutually incompatible in the same session due to MSAL/WAM conflicts #3576
• Internal validation PR: Isolate Graph authentication assembly loading PrzemyslawKlys/msgraph-sdk-powershell#1