🪲 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:

entra-powershell/src/EntraModuleBuilder.ps1

Line 390 in 07e3992

" @{ ModuleName = '$($_.ModuleName)'; ModuleVersion = '$($_.RequiredVersion)' }"

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.