TLDR: I know. We need to test very specific versions of these modules against very specific versions of PSU and publish a compatibility matrix. The technical solution isn’t an easy fix and ever changing.
Long story:
It is a bit more complicated than just running the modules in a separate process as that is what PSU is already doing. If you set up minimal environments in PSU that use pwsh.exe, it won’t load any PSU libraries like you are suggesting. If you setup PSU with environments that use pwsh.exe but aren’t minimal, it loads host DLLs that have an assembly base path of the libraries in the PSU install dir and not necessarily pwsh.exe install dir.
The greater problem is that this is a moving target with at least 4 packs of assemblies that are constantly changing. For example, EXO, Graph and Teams all used different Microsoft.Identity.Client assembly versions, while PSU used the latest version. One example of this moving target is that Microsoft actually introduced a breaking change in the assembly in a non-major build. For example, 1.30.0 works but if you upgrade to 1.50.0, it no longer has the methods required by the module. They removed a public method in the latter versions (MissingMethodException). This is exactly what caused one issue between PSU and these modules.
This isn’t limited to just PSU, as Microsoft is also struggling to keep these modules working in their own products.
The problem gets worse if you start to mix the modules together. Because PowerShell requires modules to implement an assembly load context per module, if any of the modules don’t implement it properly, we get assembly binding issues. It’s also problematic if Microsoft makes breaking changes in non-major versions because, even with ALCs implemented, they may be implemented in a way that doesn’t expect this to happen.
All this to say, it’s a very annoying technical problem because it’s one that you can fix on your end only to be broken by an update to the Module. Additionally, it’s very easy to make a change to PSU at a later time via a Nuget package update to an unrelated package, that just happens to update a dependency of one of the modules. Additionally, mixing modules or loading modules in different orders can cause issues so tests even become a bit tricky.
We’ve taken some steps in 5.5.0 that make this work but also hopefully help prevent this from happening in the future. I don’t think it’s a golden ticket.
- Reduce dependencies in our host and cmdlets assemblies
- Pin to a specific version of Microsoft.Identity.Client that works for all modules and PSU
- Setup tests to ensure we catch updates to problematic assemblies even if they aren’t directly referenced
We are also looking to setup a test to verify modules directly in PSU. Effectively, we could setup a matrix of module versions, load them in PSU, perform a few operations to validate they work and then publish that as a simple table for our users to have with every release.