Microsoft.Identity.Client conflict when using PnP and EXO v2 cmdlets within same script

[thunderstorm654]

I'm using the EXO v2 cmdlets (v 2.0.4, latest) to create and apply retention label policies to sites. There is also some requirements to use PnP and lookup some info in SharePoint first.

PnP has version 4.21.0.0 of Microsoft.Identity.Client.dll (in both 1.0.4. and latest nightly 1.4.14). But the Exchange cmdlets have version 4.23.0.0 of Microsoft.Identity.Client so I get an error 'Could not load file or assembly 'Microsoft.Identity.Client, Version=4.23.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file.'

Is there an easy way to resolve this mismatch so I can use both modules (I have limited knowledge here if there's an obvious solution), or possibility PnP will be upgraded to the later version at any point?

Any advice much appreciated!

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days

[ToddKlindt]

It looks like the 2.0.3 version of ExchangeOnlineManagement doesn't use Microsoft.Identity.Client.dll. If you can do what you need with that version you could add import-module ExchangeOnlineManagement -MaximumVersion 2.0.3 at the beginning of your script to force that version to load. If the old version isn't installed on your machine you can install it with Install-Module ExchangeOnlineManagement -MaximumVersion 2.0.3.

[thunderstorm654]

Thanks for the reply. I did try that, but I am using these in an Azure Durable Function, running on PowerShell 7. EXO only works from 2.0.4 with PowerShell 7 as they only recently made that update!

For now I managed to work around the issue by importing the modules manually into the function via import statements, and not allow either managed dependencies or a standard Modules folder to auto load them. If I import both in manually before using either, it seems to force using the later version of Identity.Client. Only importing PnP and running cmdlets, then later trying to import EXO and connect will result in the error as the older assembly is then in memory I believe. I'm not an expert in this area by any stretch but this sort of makes logical sense (I think!).

Bit weird though as within our Dev team we had mixed results replicating this locally, some of us would get the conflict and others not (even when not having installed the modules and just importing via the psd1 manually to mimic what should be happening in Azure). However results running the function in Azure were consistent so must have had some odd local config differences.

[ToddKlindt]

It sounds like you have a pretty good handle on it. I'm not an expert on the order PowerShell goes through when it autoloads modules, but it would make sense that it would load PnP first if your script uses that first, and EXO later. I can see how it would break if PnP autoloads first with an older version than works with EXO.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days

[pschaeflein]

The Az module for Azure also has a conflicting version of Microsoft.Identity.Client.

This issue can be resolved by including the Microsoft.Identity.Client assembly in the alternative AssemblyLoadContext that is used for Application Insights.

[gautamdsheth]

We have updated the MSAL.NET to 4.36.1, nearly the latest one.
Can you give it a try with the latest nightly and check ?

[thunderstorm654]

Since the update to 4.36.1, I cannot use PnP 1.8.0 as well as the 'latest' (though quite a while since release now) EXO 2.0.5. EXO 2.0.5 MSAL is on 4.30.1.0, same version as PnP 1.7.0. If I use PnP 1.7.0 and EXO 2.0.5 all is well, since MSAL versions match exactly for once.

However I cannot use PnP 1.8.0 at all alongside EXO 2.0.5, as it always complains it cannot find the Microsoft.Identity.Client.dll version 4.36.1. Swapping load order doesn't fix it anymore. I guess back a few months ago when I originally posted, EXO had the newer version of MSAL and PnP was behind. Seems now PnP is ahead EXO is just a PITA and causes PnP to stop working.

But yes I noticed a problem with Az as well... god this is a nightmare! I don't get assembly load errors though. Just at the end of my function I use Az.Storage to write a message to a different storage account queue, and this would fail if I had already used PnP/EXO already. I got around it by forcing using an Az cmdlet first in my function app, then everything seems to work. This one is particularly odd since the version of Az I have has the 4.30.1.0 MSAL as well, so perhaps there's some other conflict going on with that.

As an aside, Az 2.5.3 currently works fine with PnP 1.8.0 in Azure Functions, it was only since I added EXO into the mix that it stopped working and had to do this crazy stuff. I'm going to blame everything on EXO at this point for causing nightmares... the irony is we don't even really want to use EXO cmdlets at all, just there's no other way to interact with the compliance center to apply label policies (and some other pieces) at the moment. Cannot wait for everything to make it into Graph!

[gautamdsheth]

Can you try with the previous version of PnP i.e 1.7.0 ? That has MSAL compatible with Az modules.

[gautamdsheth]

Closing this now ! Not sure if we can do anything from our side to fix. We try to keep the MSAL in sync with Az modules but way too many modules use different versions.

[pschaeflein]

@gautamdsheth This can be resolved by moving the reference to MSAL into the PnP.PowerShell.ALC project/assembly.

https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/understanding-assemblyloadcontext

[SjoerdV]

@gautamdsheth could we re-open this issue? As interoperability with other modules might be a good thing to have. @pschaeflein has a good suggestion btw.

[andyleejordan]

@pschaeflein is correct, and was correct two years ago. The AssemblyLoadContext as implemented in PnP.PowerShell is only isolating Microsoft.ApplicationInsights, and PnP.PowerShell has a lot more dependencies (namely Microsoft.Identity.Client) that conflict and need to be isolated in the same manner.

@gautamdsheth this is fixable, it's just probably a lot of work.

[fpsacha]

This fix need to happen.

[fpsacha]

This amazing powershell module is just painfull to use.

Connect-PnPOnline -url $AdminSiteURL -ClientId $AppID_PnP -Te …
ERROR: | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR: | Could not load file or assembly 'PnP.PowerShell.ALC, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null'. Uncaught
ERROR: | exception during type initialization. (0x80131534)