DLL Mismatch with Az.Accounts

[wilfman01]

The new version of Az.Accounts is throwing up this error "WARNING: INITIALIZATION: Fallback context save mode to process because of error during checking token cache persistence: 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. (0x80131621)." when doing a connect-AzAccount.

When I look at what assemblies are loaded using [System.AppDomain]::CurrentDomain.GetAssemblies() | Where {$_.location -like "identity"} | FL I can see a previous DLL loaded from MSAL.PS PowerShell/Modules/MSAL.PS/4.21.0.1/Microsoft.Identity.Client.4.21.0/netcoreapp2.1/Microsoft.Identity.Client.dll

Is it possible to update the dependency or advise on how I can fix. I tried removing the modules and installing Az.Accounts first but that has not fixed it.

[JAK1047]

We've also encountered the exact same issue. Any update on this would be appreciated.

[devlie]

We found that MSAL.PS does not play nice with Az.Powershell.

• If MSAL.PS is loaded first, Az.Powershell will complain about not being able to load Microsoft.Identity.Client.
• If Az.Powershell is loaded first, MSAL.PS will return:

  Get-MsalToken: The 'Get-MsalToken' command was found in the module 'MSAL.PS', but the module could not be loaded. For more information, run 'Import-Module MSAL.PS'.
  PS > Import-Module MSAL.PS
  Import-Module: Assembly with same name is already loaded
  

How can we get them to interoperate? Thanks,

[erich-wang]

Dependency assembly version conflict is inevitable in PowerShell 7 as modules are owned by different teams/companies. The key point is how each module handle the version conflict. Currently MSAL.PS is sticking to specific version of Microsoft.Identity.Client, while Az.Accounts works fine if higher version of Microsoft.Identity.Client is already loaded first. One feasible way is to change MSAL.PS to swallow exception if higher version of Microsoft.Identity.Client is already loaded.

BTW, Azure PowerShell is working on dependency assembly isolation by using AssemblyLoadContext which should solve the conflict with other modules, the plan is to release within H2 2021.

[jazuntee]

Hi everyone, I just released an update (v4.35.1.3) to address this. Hopefully there is a more elegant solution with AssemblyLoadContext that can be implemented at some point in the future but let me know if the updated module works for you.

[DarkLite1]

Strange, never had this error before but since upgrading from version 4.21.0.1 to version 4.35.1.3 we get this error:

WARNING: Assembly with same name "Microsoft.Identity.Client.Desktop.dll" is already loaded: C:\ProgramFiles\WindowsPowerShell\Modules\MSAL.PS\4.35.1.3\Microsoft.Identity.Client.Desktop.4.35.1\net461\Microsoft.Identity.Client.Desktop.dll

When running the function Get-MsalToken manually we see this:

It seems like we can't answer the question with "n". We then thought about looking at the paratemers with Get-Help Get-MsalToken to see if there is one that we can use to ignore this error but that of course asks the same question and doesn't display any parameters at all:

Reverting to the older version for now. Thank you for having another look at this.

[jazuntee]

Hmmm I think answering with "n" was working but it might have prompted twice. The third instance is just weird. That is an interesting side-effect of this prompt when using Get-Help since it depends on the module loading. Thanks for reporting that. Also, you would need to answer "y" to ignore the error and continue importing. When you do so, there are instructions for importing the module without prompting as well. @DarkLite1 could you provide what version of Windows and PowerShell you are using?

[DarkLite1]

Thank you for getting back to us. The Windows version:

PowerShell version:

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14393.4583
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.4583
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

You are correct, we should've answered with 'y' instead of 'n'. It was a busy day I guess.. :P Anyhow, when doing it correctly we see the following:

All uur modules are stored in the folder C:\Program Files\WindowsPowerShell\Modules. Would it not be a better idea to store this setting within the module folder itself? Just thinking about automation issues once someone cleans data in the AppData\Roaming folder.

Another thing we noticed when trying to save the config where suggested we get this error message:

So I'm not 100% confident that the config is saved.

[wilfman01]

Hi everyone, I just released an update (v4.35.1.3) to address this. Hopefully there is a more elegant solution with AssemblyLoadContext that can be implemented at some point in the future but let me know if the updated module works for you.

Thanks @jasoth - Looks like new release is working properly for me.

[antonGritsenko]

1:1 same story as @DarkLite1. Freshly installed module from the gallery. Any update for this?