Fix PnP ALC initializer with loaded assemblies

[FabienTschanz]

Type

• Bug Fix
• New Feature
• Sample

Related Issues?

• Fixes [BUG] Process crashes with a stack overflow in Connect-PnPOnline after Teams or EXO Module connected (3.4.0 and later) #5480

What is in this Pull Request ?

Fixes the PowerShell process crash (stack overflow) in Connect-PnPOnline when another module, such as MicrosoftTeams or ExchangeOnlineManagement, has already loaded an older Microsoft.Identity.Client into the default AssemblyLoadContext. This is a regression from #5393 (3.4.0).

PnPAssemblyLoadContext.Load deferred a boundary assembly (Microsoft.Identity.Client*, System.Text.Json) to the default context whenever the default context held an assembly with that name, regardless of its version. When that copy is older than the one PnP references, the loop goes like this:

1. The default context cannot bind the reference and raises Resolving.
2. ResolveDependency routes the request to the private context.
3. The private context defers it back to the default context, which raises Resolving again.

This repeats until the stack overflows.

Changes:

• PnPAssemblyLoadContext.DefersToDefaultContext replaces IsLoadedInDefaultContext. A boundary assembly defers only when the default context holds a copy that PnP does not ship, or one at least the version PnP ships.
  • Microsoft.Identity.Client.* assemblies defer only when Microsoft.Identity.Client itself defers, so the private context never pairs its own MSAL with a host copy of an MSAL extension.
  • Otherwise the private context loads its own copy, and ResolveDependency routes PnP.PowerShell.dll's reference to that copy as well.
• ResolveDependency no longer routes a deferred boundary assembly into the private context, which is what closed the loop. It returns, in this order:
  1. the copy the private context has already loaded.
  2. otherwise the default context's copy, if that copy satisfies the requested version.
  3. otherwise null.

How this was tested

I tested this with both PowerShell 7.6.6 (.NET 10) and with 7.4.20 (.NET 8) with the same results.
Note: "Connect" means Connect-PnPOnline with a throw-away certificate against a tenant that doesn't exist. Reaching AADSTS90002 means MSAL ran.

Default context before Connect	dev	this PR
nothing	OK	OK
MSAL 4.90 (newer)	OK, shares the host copy	OK, shares the host copy
MSAL and Extensions.Msal 4.90	OK, shares both	OK, shares both
MSAL 4.85.2 (same version)	OK, shares	OK, shares
MicrosoftTeams 8.0.0 family, 4.82	crash	OK, own 4.85.2
MSAL 4.82 with Extensions.Msal 4.90	crash	OK
MSAL 4.82 loaded after Import-Module PnP.PowerShell	crash	OK
MSAL 4.90, another caller loads MSAL 4.95	crash	FileNotFoundException for that load
MSAL 4.90 lands in the default context while PnP's first bind is in flight (forced interleaving)	crash	OK
MicrosoftTeams 8.0.0 family, Connect-PnPOnline in 6 ForEach-Object -Parallel runspaces	crash	OK

Tested against a tenant with app-only certificate authentication, in three orders:

• Connect-MicrosoftTeams, then Connect-PnPOnline
• Connect-ExchangeOnline, then Connect-PnPOnline
• PnP first, then Microsoft Teams and Exchange Online.

All three connect, and Get-PnPTenant, Get-CsTenant and Get-OrganizationConfig keep working afterwards. The released 3.4.1 and unpatched dev crash in the first two orders.

[gautamdsheth]

Thanks @FabienTschanz , merged it !!
Much appreciated you creating and fixing the issue, will be available in tomorrow's nightly builds as well as next major version

[FabienTschanz]

Thank you, will check it out tomorrow!