🪲 Bug report - Az.Storage and ExchangeOnlineManagement with Get-EXO cmdlets

[a-nicholls]

Description

Trying to connect Az.Storage and ExchangeOnlineManagement together in Azure Runbook running PowerShell 7.6, as soon as you use a Get-EXO cmdlet like Get-EXOMailbox it returns a DLL related error

Expected Behavior

The cmdlet should just work with the help of your module

Current Behavior

Currently tested with PowerShell 7.4 and 7.6 in Azure Runbook with ExchangeOnlineManagement 3.9.0 and 3.9.2 with Az.Storage 9.6.0. (with other Az modules)
connecting to Azure Storage first then using Connect-ExchangeOnline,
it's when I run Get-EXOMailbox that it comes up with the error

Could not load file or assembly 'Microsoft.OData.Core, Version=7.22.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)

This explains the situation;
Azure/azure-powershell#14416
now I've tried the workaround by randomnote1 Oct 25, 2024
Azure/azure-powershell#14416 (comment)
and that has worked, albeit with having to overwrite files and creating a customised Az.Storage module with the dll files from ExchangeOnlineManagement.

Possible Solution

Is it possible for this module to workaround this issue wihtout having to use a customised Az.Storage module?

Steps to Reproduce

Create runbook environment with Az.Storage 9.6.0 and ExchangeOnlineManagement 3.9.0/3.9.2 modules as above

Import-Module DLLPickle
Import-DPLibrary

import-module Az.Storage
import-module ExchangeOnlineManagement

Connect-ExchangeOnline -ManagedIdentity -Organization $TenantName
Get-EXOMailbox

Context (Environment)

I'm trying to be able to export mailbox details and perform actions upon them, but also need to save results hence why I need to use the Az.Storage component with a Managed System Identity.

Note I'm testing this within an Azure RunBook

• Operating System and version as reported by $PSVersionTable.OS: Microsoft Windows 10.0.20348
• PowerShell versions as reported by $PSVersionTable.PSEdition: Core

[SamErde]

Thanks for reporting this. I'll have to research more to determine if it's related to DLL Pickle, the environment, or other modules.

[SamErde]

Update: PR #183 now includes automation to keep this compatibility boundary visible over time.

The PR adds a dependency policy and scheduled upstream compatibility workflow that inventories the latest PSGallery releases of ExchangeOnlineManagement, Az.Storage, Az.Accounts, Microsoft.Graph.Authentication, and MicrosoftTeams. OData-family assemblies are tracked as report-only/blocked preload families because testing showed that preloading ExchangeOnlineManagement's OData version can break Az.Storage when it expects a different OData identity.

This means future OData drift should be detected and reported with workflow artifacts instead of being auto-added to DLLPickle's default preload set. The current recommendation remains process isolation for incompatible Az.Storage + EXO OData workloads unless a future safe isolation strategy is implemented.

[SamErde]

Scratch that. I have burned a ton of credits on this and come to the conclusion that DLL Pickle will only reliably work with the desired Microsoft PowerShell modules if I abandon efforts to simultaneously support PowerShell and Windows PowerShell 5.1 (or Windows PowerShell at all)!

I'm strongly leaning towards stripping out all .NET Framework and Windows 5.1 handling. Any thoughts on that change?

[SamErde]

One last attempt is now in progress in PR #186: #186

This branch keeps #174 documented and tested as an in-process dependency boundary rather than adding an unsafe default OData preload. The repro work found that Az.Storage and ExchangeOnlineManagement can require incompatible Microsoft.OData assemblies in the same process, and preloading the newer OData family can break Az.Storage import. The updated docs recommend isolating Az.Storage and ExchangeOnlineManagement workloads into separate PowerShell processes when both dependency lines are required.

The same PR also adds the base-profile import helper and upstream dependency policy coverage for the identity stack.

[SamErde]

I finally found time to work on this and am about to add support for multiple target frameworks so the module can properly update and import the newest relevant libraries in PowerShell 7.4 (.NET 8), 7.5 (.NET 9), 7.6 (.NET 10), and the 7.7 preview (.NET 11 preview). Fingers cross, this will make things a lot more stable and predictable!

[SamErde]

Investigating. I can still reproduce this problem with DLL Pickle 2.1.2 in PowerShell 7.6 on Windows. Should be close to a fix now, though!