Az-Accounts: Issue re-emerging..

[RRanks]

Error:

Unable to load Graph PS Module

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

Previously the issue was apparently resolved via this patch: https://github.com/Azure/azure-functions-powershell-worker/issues/1010

However, it appears to have come back perhaps with patches released.,, Az.Accounts 2.15?

[RRanks]

Requirements.psd1 @{

For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'. Uncomment the next line and replace the MAJOR_VERSION, e.g., 'Az' = '5.*'

#'Az' = '11.*'
'AzAuth' = '2.*'
'AzTable' = '2.*'
'Az.Accounts' = '2.*'
'Az.Resources' = '6.*'
'Az.Storage' = '5.*'
'Az.KeyVault' = '4.*'
#'AzureAD' = '2.*'
'ExchangeOnlineManagement' = '3.*'
'MicrosoftTeams' = '4.*'
#'Microsoft.Graph' = '2.15.0'
'Microsoft.Graph.Groups' = '2.*'
'Microsoft.Graph.Authentication' = '2.*'
'Microsoft.Graph.Users' = '2.*'

}

[andystaples]

Hi @RRanks, Upon initial review, it appears most likely to me that your issue is a dependency conflict within your modules, and not a return of the platform issue from #1010. This type of error is somewhat common in PowerShell functions which use more than a handful of dependent packages, due to PowerShell loading all modules and their required binaries into the default assembly load context. We are working on publishing a user guide for this scenario, but our general recommendation for avoiding/preventing these types of errors is as follows:

1. Figure out which of the modules from requirements.psd1 utilize the .dll which is in conflict (in this case, Microsoft.Identity.Client). You can utilize Save-Module on your local machine to download the modules and examine their contents to figure out if they are using this dll and which version they use.
2. Pin these modules to a specific minor version to prevent the managed dependencies feature from auto-upgrading them and introducing breaking conflicts.
3. In profile.ps1, explicitly import each module using Import-Module with the -RequiredVersion parameter. Import the modules in order from highest Microsoft.Identity.Client version to lowest.
4. Run the function app. If you are still getting errors, take note of which Import-Module statement is failing, and move it higher in the list.

5. If you are unable to resolve the issue using these steps, you may have a circular dependency conflict. At this point, there are some further alternatives.

Either

a) You could try running fragile modules in windows compatibility mode. This will isolate those modules into their own powershell instance and therefore, their own assembly load context. Instructions and disclaimers for this approach can be found here

or

b) Splitting the function app into multiple apps each using minimal sets of modules can help prevent modules from conflicting with each other.

If none of these approaches are successful or acceptable, please reach out to our Azure support staff who may be able to further assist. https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

[RRanks]

@andystaples

Hi @RRanks, Upon initial review, it appears most likely to me that your issue is a dependency conflict within your modules, and not a return of the platform issue from #1010. This type of error is somewhat common in PowerShell functions which use more than a handful of dependent packages, due to PowerShell loading all modules and their required binaries into the default assembly load context. We are working on publishing a user guide for this scenario, but our general recommendation for avoiding/preventing these types of errors is as follows:

1. Figure out which of the modules from requirements.psd1 utilize the .dll which is in conflict (in this case, Microsoft.Identity.Client). You can utilize Save-Module on your local machine to download the modules and examine their contents to figure out if they are using this dll and which version they use.
2. Pin these modules to a specific minor version to prevent the managed dependencies feature from auto-upgrading them and introducing breaking conflicts.
3. In profile.ps1, explicitly import each module using Import-Module with the -RequiredVersion parameter. Import the modules in order from highest Microsoft.Identity.Client version to lowest.
4. Run the function app. If you are still getting errors, take note of which Import-Module statement is failing, and move it higher in the list.

If you are unable to resolve the issue using these steps, you may have a circular dependency conflict. At this point, there are some further alternatives.

Either

a) You could try running fragile modules in windows compatibility mode. This will isolate those modules into their own powershell instance and therefore, their own assembly load context. Instructions and disclaimers for this approach can be found here

or

b) Splitting the function app into multiple apps each using minimal sets of modules can help prevent modules from conflicting with each other.

If none of these approaches are successful or acceptable, please reach out to our Azure support staff who may be able to further assist. https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

I FOUND THE ISSUE >> Seems to be the file location changes. And unable to use the "-RequiredVersion" parameter to call an older version

None of the above resolved the issue.. here is what I have found...

I setup a function with just Import-Az.Accounts using the older required version that was working with the previous issue 5months ago. V2.13.2.

It then errored saying it was using V2.16, and Microsoft confirmed it will import the latest version of Az.Accounts no matter what version I add the required value as. However... The V2.16.0 does not have the same internal folder structure so the fix in #1010 - Is not causing this issue in.. the new version as all the files are in the "netstandard2.0" folder not "netcoreapp2.1" and not "netcoreapp3.1".

Without the patch from the #1010 - It does not work however.. the fix now needs to be updated to the correct path:

Import-Module Az.Accounts $azAccountsLibPath = Join-Path (Split-Path (Get-Module Az.Accounts).Path -Parent) "lib" Add-Type -AssemblyName (Join-Path $azAccountsLibPath "netstandard2.0" "Microsoft.IdentityModel.Abstractions.dll") Add-Type -AssemblyName (Join-Path $azAccountsLibPath "netstandard2.0" "Microsoft.Identity.Client.dll") Add-Type -AssemblyName (Join-Path $azAccountsLibPath "netstandard2.0" "Microsoft.Identity.Client.Extensions.Msal.dll") Connect-AzAccount -Identity

error when trying to use RequiredVersion: V2.13.2 2024-04-02T03:44:56Z [Error] ERROR: Could not load file or assembly 'C:\home\data\ManagedDependencies\2404020332440659854.r\Az.Accounts\2.16.0\lib\netcoreapp2.1\Microsoft.Identity.Client.dll'. The system cannot find the file specified.

More screen shots attached..

[RRanks]

Oh I also dropped the Graph connections back down to the 5 months ago version.. not tested upgrading them again yet. 'Microsoft.Graph.Groups' = '2.9.1' 'Microsoft.Graph.Authentication' = '2.9.1' 'Microsoft.Graph.Users' = '2.9.1' 'Microsoft.Graph.Education' = '2.9.1' 'Microsoft.Graph.Calendar' = '2.9.1'