[BUG] Using PnP with ExchangeOnlineManagement - Could not load file or assembly 'Microsoft.Identity.Client, Version=4.36.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file. (0x80131621)

[svermaak]

Reporting an Issue or Missing Feature

Using PnP with ExchangeOnlineManagement - Could not load file or assembly 'Microsoft.Identity.Client, Version=4.36.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file. (0x80131621)

Expected behavior

Use PnP PowerShell successfully with ExchangeOnlineManagement

Actual behavior

Steps to reproduce behavior

See screenshot

What is the version of the Cmdlet module you are running?

Latest

Which operating system/environment are you running PnP PowerShell on?

• Windows
• Linux
• MacOS
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[kilicantplay]

This is an issue with the VSCode PowerShell Extension and PnP.PowerShell. Last update was Don't count on this ever being fixed

Either use 5.1 or the Console

[svermaak]

In my example, I am executing it in the console. Also, the way I read the other thread is to use PowerShell Core (AKA 7) which I am also doing. This worked for months and only recently stated failing

[svermaak]

Any ideas?

[kilicantplay]

The only other thing I've come across with the EXO module was that you had to have basic Auth enabled, but I don't think that would effect what you're doing in this instance.

Could you sanitise the script and I can try to replicate on my tenant

[svermaak]

save-module ExchangeOnlineManagement -Path .\;
save-module pnp.powershell -path .\;
Import-Module .\PnP.PowerShell\1.10.0\PnP.PowerShell.psd1;
Import-Module .\ExchangeOnlineManagement\2.0.5\ExchangeOnlineManagement.psd1;
$runAs = [PSCustomObject]@{
    "ClientId"   		= "xxx"
    "Thumbprint" 		= "xxx"
    "Tenant"     		= "xxx"
    "Organization"     	= "xxx"
};
Connect-ExchangeOnline -AppId $RunAs.ClientId -CertificateThumbprint $RunAs.Thumbprint -Organization $RunAs.Organization -ErrorAction Stop -ShowBanner:$false;
Connect-PnPOnline -Url "xxx" -ClientId $RunAs.ClientId -Thumbprint $RunAs.Thumbprint -Tenant $RunAs.Tenant -ReturnConnection -ErrorAction Stop;

[svermaak]

The ExchangeOnlineManagement loads a Microsoft.Identity.Client, Version=4.30.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae and PnP.PowerShell is expecting Microsoft.Identity.Client, Version=4.36.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae. I thought PowerShell Core has some fancy way of isolating the binaries

[gautamdsheth]

Am transferring this to discussions as this is not an issue with PnP PowerShell command executions.

[svermaak]

I can use PnP 1.7 with ExchangeOnlineManagement 2.0.5 because they use the same Microsoft.Identity.Client.dll. Any Ideas on how to use 1.10 without DLL conflict?

[pttbr]

I'm having the same problem with this installed:

Powershell version: 7.2.3
PnP.Powershell version: 1.10.0
ExchangeOnlineManagement version: 2.0.5

The error is:
Connect-PnPOnline: Could not load file or assembly 'Microsoft.Identity.Client, Version=4.36.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file. (0x80131621)

It only happens if I connect to Exchange before PnP.Powershell and it only happens in Powershell 7.x

Script: ExchangeFirst.ps1

#requires -module ExchangeOnlineManagement
#requires -module PnP.PowerShell

Connect-ExchangeOnline -CommandName Get-UnifiedGroup
Connect-PnPOnline -Url "https://mycompany.sharepoint.com" -Interactive

Script: PnPFirst.ps1

#requires -module PnP.PowerShell
#requires -module ExchangeOnlineManagement

Connect-PnPOnline -Url "https://mycompany.sharepoint.com" -Interactive
Connect-ExchangeOnline -CommandName Get-UnifiedGroup

[svermaak]

I have had temporary success with a combination of commenting out some/all '.\netCore\Microsoft.Identity.* dll in ExchangeOnlineManagement.psm1 and/or taking the Microsoft.Identity.* dll from PnP.PowerShell and replacing them in ExchangeOnlineManagement. Seems ExchangeOnlineManagement doesn't care what version is loaded but PnP.PowerShell is very specific about which version of Microsoft.Identity.* dll is loaded and simply refuses to work with one other that the one that is part of the build.

[daverickdunn]

Well, that was painful...

Great spotting @pttbr

[jerome-dl]

@pttbr made my day (after 3 days of suffering!) Thanks ❤

[PowerBugi]

I can confirm @pttbr comment

I have the pretty same config except that i'm using the new 2.0.6-Preview6 Exchange module.
If i connect Exchange before PnP it work.
Otherwise it fail (with the same error in the title of the issue).

[svermaak]

Unfortunately ms me it doesn't if you go back and forth between them Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: PowerBugi ***@***.***> Sent: Saturday, June 18, 2022 1:37:51 AM To: pnp/powershell ***@***.***> Cc: svermaak ***@***.***>; Author ***@***.***> Subject: Re: [pnp/powershell] [BUG] Using PnP with ExchangeOnlineManagement - Could not load file or assembly 'Microsoft.Identity.Client, Version=4.36.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file. (0x80131621) (... I can confirm @pttbr<https://github.com/pttbr> comment I have the pretty same config except that i'm using the new 2.0.6-Preview6 Exchange module. If i connect Exchange before PnP it work. Otherwise it fail (with the same error in the title of the issue). — Reply to this email directly, view it on GitHub<#1814 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC5RDEBM3HCT5KWMP5BUVWTVPSLU7ANCNFSM5U2QZJPA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[seanboltman]

[seanboltman]

Solution, mine. Its true that if you connect to multiple things to perform your work, you will run into issues with DLL versions being incorrect for one but not another. What you have to do is split it up.

I have a PS7 automation script that provisions SPO modern sites. It creates sites, renames them, applies site templates, hides them from the global address book, etc. All these pieces of work to create one given site requires multiple connects. One other thing, all these connections are required to be modern auth... no secure string password saves on local.

You cannot have all these connections in a single inline script. As we all know now.

So my [main] script starts off using Connect-PnpOnline:

Connect-PnPOnline -Url $onlineSiteDirectoryHostUrl -ClientId (ConvertFrom-SecureString $spClientID -AsPlainText) -ClientSecret (ConvertFrom-SecureString $spClientSecret -AsPlainText) -WarningAction Ignore

Eventually it gets to a point where is has to create a default SPO Modern site. I had to use Graph API for this, and this is it's own dedicated PS7 script.
First, here is how I invoke that secondary script from the main script:

---

        ############################################################################################
        # Pre-Create new modern Project Site
        ############################################################################################

        $groupCreated = $false
        try
        {
            # Create new modern team site
            $testResult = Start-Job -ScriptBlock {C:\SharePointOnlineSupport\Scripts\Helper-Graph-CreateSiteGroup.ps1 -ProjectID $args[0] -ProjectName $args[1] } -ArgumentList $projectId, $preCreatedProjectName  | Receive-Job -Wait
            if ($testResult[$testResult.Count - 1] -eq 200)
            {
                $groupCreated = $true
            }
        }
        catch
        {
            logError("SPO Site pre-creation failed error: " + $_.Exception.Message)
            continue
        }
        logInfo("Precreated SPO Site: $projectId")

---

This code clip invokes an external script, and blocks on it, waiting for it to finish.

Here is the code for that secondary script. I connects to Graph using MSAL, creates a new site group, and then issues a web request to hide that new site group from the GAL (Sorry for the whack formatting, just ignore it. Code clip ends with "return 200"):

Import-Module MSAL.PS
$MsalToken = Get-MsalToken -TenantId (ConvertFrom-SecureString $tenantId -AsPlainText) -ClientId (ConvertFrom-SecureString $msalAppId -AsPlainText) -ClientSecret $msalClientSecret -AzureCloudInstance 1
Connect-Graph -AccessToken $MsalToken.AccessToken

###############################################################

Create the Site Group, and then update it's Outlook settings

###############################################################

logInfo("Creating new project site group: $ProjectID ")

$params = @{
Description = $ProjectName
DisplayName = $ProjectName
GroupTypes = @(
"Unified"
)
MailEnabled = $false
MailNickname = $ProjectId
Visibility = "Private"
SecurityEnabled = $false
}

New-MgGroup -BodyParameter $params
logInfo("New-MgGroup executed")

Start-Sleep 30

Hide from Outlook

$grp = Get-MgGroup -Filter "MailNickName eq '$ProjectID'"
logInfo("Get-MgGroup executed... Group: " + $grp)

Start-Sleep 10

build a REST PATCH call and invoke - This is to HIDE the Group from within Outlook!!!

$headers = New-Object 'System.Collections.Generic.Dictionary[String,String]'
$bearer = "Bearer " + $MsalToken.AccessToken
$headers.Add("Authorization", $bearer)

$body = @"
{"hideFromOutlookClients":"true"}
"@

$apiUri = "https://graph.microsoft.com/v1.0/groups/" + $grp.Id

$attempts = 1

logInfo("Before Invoke-WebRequest to hide group from GAL: " + $apiUri)

while ($attempts -le 6)
{
try {
# Invoke-RestMethod -Headers $headers -Uri $apiUri -Body $body -Method PATCH -ContentType 'application/json'
Invoke-WebRequest -Headers $headers -Uri $apiUri -Body $body -Method PATCH -ContentType 'application/json'

    logInfo("HidingGroupFromOutlook SUCCESS in Helper-Graph-CreateSiteGroup.ps1")
    return 200
}
catch {

    logError("HidingGroupFromOutlook FAILED in Helper-Graph-CreateSiteGroup.ps1 ( $apiUri ) Attempt # $attempts -> " + $_.Exception.Message)

    Start-Sleep 30
    $attempts++
}

}

Geo-SendEmail -To "sboltman@abc.com" -Subject "HidingGroupFromOutlook FAILED in Helper-Graph-CreateSiteGroup.ps1" -Body ("HidingGroupFromOutlook FAILED in Helper-Graph-CreateSiteGroup.ps1 -> $apiUri -> Attempt: $attempts -> " + $_.Exception.Message)

return 200

This main script of mine calls out to three "helper/secondary" scripts like the clip from the one above.

By segregating out these various APIs into their own callable scripts, can you avoid this maddening DLL version conflicts.

I always hope for finding real function code example when I research issues. I hope this one hopes others.

[PowerBugi]

I discovered what seems to be the cause of the problem.

the DLL : Microsoft.Identity.Client.dll of the other modules.

Basically :

• If you have ExchangeOnlineManagement, MicrosoftTeams, Mailozaurr, etc... Installed (a module that uses the DLL mentioned above).
• And that these modules use a version of the DLL PRIOR to the one of the PnP.PowerShell module (not very recent version for example).
• AND THAT you have loaded these modules BEFORE loading the PnP module : THEN YOU WILL GET THIS ERROR MESSAGE.

Example :

I run PowerShell and I run the Send-EmailMessage cmdlet of the Mailozaurr module (This module uses the Microsoft.Identity.Client DLL version 4.36.0.0) so the DLL is now loaded.
Then I run Connect-PnPOnline -Url https://mytenant-admin.sharepoint.com/ -Credentials (Get-Credential) then : I have the bug !
(NOTE : I get the same error message when typing "Connect-ExchangeOnline" because the EXO module must use a more recent DLL : 4.44.0.0).

It is not possible to "unload" a DLL, so once the old DLL is loaded, it is too late.

On the other hand, if I run PowerShell and run the Connect-ExchangeOnline cmdlet (with version 3.1.0 which uses the 4.44.0.0 DLL), then I can run the Connect-PnPOnline command without any problem just after (because the DLL is > 4.36.1.0).

By the way, you can check which DLL is loaded after each command to verify this theory, with this command :
[System.AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {$_.FullName -match "Microsoft.Identity.Client"} | Select-Object -Property FullName, Location | fl

Also, I had fun loading the ExchangeOnline module DLL myself with this command in new PowerShell session :

$null = [System.Reflection.Assembly]::LoadFrom("C:\Program Files\PowerShell\Modules\ExchangeOnlineManagement\3.1.0\netCore\Microsoft.Identity.Client.dll")

And to run in the order Send-EmailMessage then Connect-PnPOnline -Url https://mytenant-admin.sharepoint.com/ -Credentials (Get-Credential) as before in my first example.
And there, I don't have the bug anymore ! Because the DLL loaded is = 4.44.0.0.

So the question is... Is it possible to avoid this problem without having to check the dll version and/or having to load this or that module before another one... ?

[rajarshibhargav]

Does the community know of a compatible version of PNP with 3.1.0 ExchangeOnlineManagement? We want to use EXOv3 with PNP DLL.

[PowerBugi]

Stupid solution :

Copy the Microsoft.Identity.Client.dll file in the module folder of EXO or Graph for example, and paste it (and overwrite) in the [...]\Mailozaurr\1.0.0\Lib\Core\Microsoft.Identity.Client.dll

And so you have the same version so no error anymore...

[efd7887]

This is just terrible design throughout the entire framework. Why would you write multiple modules requiring multiple versions of a library? Where is the centralization? And to simply say this version of the DLL can do this and the other can't is just a crutch. I have been battling this for some time and its beyond frustrating to say the least. If you have that many issues within a framework, why no stop dragging dead bodies forward and fix the root issue?

[AndersRask]

While I do understand your frustration (trust me, I've been there!), you need to remember that PnP.PowerShell is a comunity driven project, that the developers (be it Microsoft or not) do on their own time.
So aligning with existing Microsoft driven modules like Az and EXO is difficult for this and many other reasons. Some modules will always be ahead, and some behind -like now with PnP.PowerShell 2.x where it was deemed necessary to upgrade to .NET 6 due to older frameworks getting out of support.
However I do agree, that there need to be extremely good reasons for loading specific assembly versions (instead of loading by name).
From my testing so far combining these modules, the issue is that if versions differ too much, certain methods are not exposed, and hence even if you find a way to load the same assembly for different modules, they simply wont work.
I suggest you test different versions out, with the modules you require, and it should be possible to find versions where they all coexist fine if loaded in the correct order (eg using same or very similar assemblies). Try to load PnP.PowerShell last, as I've found that module to be the one requiring specific assembly versions.
Alternatively split your workload into different runspaces (look up PowerShell documentation for different supported scenarios)

[goldenplayer5630]

For everyone still looking, I might have a solution for you:
https://learn.microsoft.com/en-us/answers/questions/1287803/could-not-load-file-or-assembly-microsoft-identity

[AndersRask]

The issue with colliding assemblies should now be fixed!
#3207

[PowerBugi]

Look like it don't work for me, i still have error :

Could not load file or assembly 'Microsoft.Identity.Client, Version=4.50.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. Could not find or load a specific file. (0x80131621)

Using multiples modules in the same script :

Module	Version
Microsoft.Graph	2.2.0
ExchangeOnlineManagement	3.2.0
PnP.PowerShell	2.2.0

If i connect to PnP first, it's ok... But if i connect to ExO & Graph first, and try to connect to PnP in the same session, i have the error.

I found a fix so i don't have to think about it :
When PowerShell is starting, I pre-load the highest version of 'Microsoft.Identity.Client' file using a script that scan all my installed modules and then import the latest version file automaticaly, like :

$DLL_MicrosoftIdentityClient = Get-ChildItem 'Microsoft.Identity.Client.dll' -Path 'C:\Users\xxxxxx\Documents\PowerShell\Modules\' -Recurse
$LastVersion = $DLL_MicrosoftIdentityClient.VersionInfo | Where-Object { $_.FileName -match "core" } | Sort-Object FileVersion -Descending | Select-Object -First 1
[System.Reflection.Assembly]::LoadFrom("$($LastVersion.FileName)")

That's stupid but... It work and i don't have to care anymore when i upgrade my modules, if the 'Microsoft.Identity.Client' file is updated or not in some modules.