🪲 Move from RequiredVersion to ModuleVersion in module manifests

[yugabe]

Describe the bug

Install-Module Microsoft.Entra
Install-Module Microsoft.Graph

The above fails, and the -AllowClobber parameter only postpones the installation error until module load-time or execution time. If any other modules/cmdlets depend on a different version of Microsoft.Graph, any Entra modules simply won't load (assembly conflicts).

The issue is caused by the Entra modules having an explicit dependency on Microsoft.Graph's corresponding modules' 2.25.0 (as of Microsoft.Entra 1.0.6), and Microsoft.Graph already has newer versions available (with bug fixes and new features).

These issues cannot be resolved by the consumer unless manually editing the installed modules' manifests to allow other versions.

Resolution:

The module declarations have to move from RequiredVersion to ModuleVersion

# Microsoft.Entra.*.psd1:

# These are currently the relevant parts in the declarations:
# Modules that must be imported into the global environment prior to importing this module
RequiredModules = @(@{ModuleName = 'Microsoft.Graph.{*ModuleName*}'; RequiredVersion = '2.25.0'; })

# Instead, it should be:
RequiredModules = @(@{ModuleName = 'Microsoft.Graph.{*ModuleName*}'; ModuleVersion  = '2.25.0'; MaximumVersion = '2.99.99'; })

See about_Module_Manifests - RequiredModules | Microsoft Learn.

This should be a simple fix.

[yugabe]

I tried to see where it gets set incorrectly, but I only found this, which seem to build with ModuleVersion: https://github.com/microsoftgraph/entra-powershell/blob/07e3992fe282f915748ecb52913f975c65f0b938/src/EntraModuleBuilder.ps1#L390

However, the published packages' .psd1s contain RequiredVersion, which cause a number of issues.

[SamErde]

This is pinned at 2.25.0 because the Microsoft.Graph.Authentication module has several significant issues in 2.26.0 and 2.26.1 that haven't been fixed. The most impactful issue is breaking changes to the authentication process that prevents sign-in to Microsoft Graph.

[yugabe]

I see, thanks for the clarification. What's the recommended way to go about this then? I use WindowsAutopilotIntune and Entra modules in a script and that cannot run, because they want to use different versions of the same assembly (whichever is called last, fails). WindowsAutopilotIntune does not pin any versions, so PSGet installs the newest versions whatever order I install the modules.

[yugabe]

As a temporary workaround until this is fixed, the solution seems to be to uninstall all newer Microsoft.Graph.* packages, install all dependent 2.25.0 packages, and then install all other modules you might need. PSGet should not install the newer Graph dependencies if any versions are already present, preventing the conflicts.

Very clunky, and should be executed with care. In my case, I'm doing this on a fresh install because I'm creating a golden image for sysprepping, so it was relatively easy to identify the dependendy graphs that caused the issues, but this solution won't hold forever either, obviously.

[SamErde]

The main issue is being tracked in microsoftgraph/msgraph-sdk-powershell #3197 so this issue can probably be closed here.

I'm curious if you can think of any other temporary workarounds or improvements to the way that module versions are pinned in manifests. The same thing is affecting Maester and many other community projects. It has made me wish PowerShell had a version pinning feature like WinGet. 🙂

[SamErde]

They just released 2.27.0! Curious if you can test it out now, @yugabe.

[yugabe]

Unfortunately I can't test, not until Tuesday at the earliest. Although I'm not really sure what I would test for exactly either. The issues I had were because an Entra package manifest declared a pinned Graph dependency version, and WindowsAutopilotIntune declares them without version numbers.

This results in transitive dependencies (like Microsoft.Graph.Authentication) possibly having multiple assembly versions installed, and when the modules are loaded, eventually there will be a conflict trying to resolve some assemblies given they have different version numbers. I haven't encountered the authentication issue you linked with either 2.25.0 or 2.26.1 (I used both, separately). Maybe explicitly loading modules in order can solve the problem as well, but I haven't tested that, and I believe it would be quite error-prone given large enough transitive dependencies in the graph.

So, in a nutshell, my issue was effectively unrelated to what underlying problems the Graph modules with version 2.26.x might have.

[KenitoInc]

@yugabe We use RequiredVersion for 2 main reasons

1. Ensure the dependent Graph PowerShell module are stable and work well with Entra PowerShell
2. Remove from the customers, the burden of figuring out which Graph PowerShell version to use incase the latest version doesn't work.

A workaround that has worked is first installing the Graph PowerShell modules that you want, then installing the Entra PowerShell root module

Install-Module Microsoft.Graph.DirectoryObjects
Install-Module Microsoft.Graph.Users
Install-Module Microsoft.Graph.Users.Actions 
Install-Module Microsoft.Graph.Users.Functions 
Install-Module Microsoft.Graph.Groups 
Install-Module Microsoft.Graph.Identity.DirectoryManagement 
Install-Module Microsoft.Graph.Identity.Governance 
Install-Module Microsoft.Graph.Identity.SignIns
Install-Module Microsoft.Graph.Applications
Install-Module Microsoft.Graph.Reports

Install-Module Microsoft.Entra -AllowClobber

[yugabe]

Thanks @KenitoInc. As I mentioned above, the AllowClobber parameter only postpones the issue to propagate during runtime and not installation time, regardless of installation order. The modules simply require different versions of the same assembly, and if you want use them side-by-side, they will break. No workaround for this, simply not possible to load two versions of the same assembly in the same assembly load space in .NET.

I understand the desire to mark this as a workaround, but it simply does not work. The only "true" workaround is if you use two different PowerShell sessions and import one set of modules in one, and the other set of modules in the other, and use some custom solution to communicate between them on the boundary. Which is obviously more trouble than it's worth for most any scenario.

[merddyin]

Public graph module is now at 2.29.1.0 and no longer has the login issue, however the Entra module still requires 2.25.0. Any chance this can be re-evaluated and perhaps updated? Really annoying to have to remove the latest Graph and reinstall a specific version if I want to use the Entra module, which is otherwise MUCH easier to use.