Unable to install older version of Microsoft.Graph

[oliverroer]

Around 6 months ago, I have installed Microsoft.Graph version 1.0.1 on my machine. That was the latest version at the time.

I then proceeded to write some scripts using this module.

Recently, a colleague of mine wanted to run these scripts from their machine.

Initially, they would run Install-Module -Name Microsoft.Graph to install the latest version (1.4.2), and then proceed to run the script.

It turned out there had been some breaking changes in the later version, and the script could not be run with this version.

They would then proceed to uninstall all installed Graph modules, and attempt to install version 1.0.1 using the following command:

Install-Module -Name Microsoft.Graph -RequiredVersion 1.0.1

This would also not do the trick, since all dependencies are written like this:

Microsoft.Graph.<Dependency> (>= 1.0.1)

and so, it'd just proceed to install version 1.4.2 of all the dependencies anyways.

I think it would be preferable that when one asks for a certain version, say 1.0.1, you actually get the modules of that version. Perhaps it would be better to declare the dependencies with their dependencies "strictly equals", instead of "greater than or equals", like so:

Microsoft.Graph.<Dependency> (= 1.0.1)

As it is currently set up, it seems to me that the versioning of Microsoft.Graph has lost all meaning. It will not matter if I ask for version 1.0.1, 1.2.0 or 1.3.1 for example, as it will just go grab version 1.4.2 of all the dependencies anyways.

For now, it seems the workaround for us is to explicitly install the dependencies we need, with that specific version. This is certainly not optimal, and seems to defeat the purpose of the Microsoft.Graph module. 😞
AB#8695

[oliverroer]

Note: This is also a potential issue for automation systems.

If this script was to run, say, on Azure DevOps, I'd like to install version 1.0.1 of the modules as a step, before running the script.

This would have worked nicely 6 months ago, when version 1.0.1 was the latest, and then suddenly start breaking as newer versions with breaking changes are released.

[oliverroer]

Turns out it the workaround was actually worse than that.

I had to write a script that would recursively download all dependencies with the correct versions, and even then version 1.4.2 would still sneak in there, so I had to extend the script to uninstall version 1.4.2 afterwards.

[peombwa]

@oliverroer, sorry about that.

We were initially blocked by a dependency resolution issue in PowerShellGetv2 when were in preview hence the current version logic. The issue is no longer present, and we can update our required dependency versions to [1.4.2] i.e. =1.4.2. We will address this in the upcoming releases and make it easy for customers to install older versions.

Thanks for bringing this to our attention.

Related to #194 and #347 .

[georgend]

@peombwa Would older versions of service modules work with currently deployed metadata?

[peombwa]

@georgend at a minimum, older versions should always work for v1.0 profile.

[peombwa]

After experimenting with this, it looks like we won't be able to support this due to our current Authentication module dependency structure. Due to PowerShell 5.1 strict dependency requirements, customers will get the following error:

Windows PowerShell 5.1 (fails)

PowerShell 7.1.3 (works as expected)

The solution here is for us to move away from project dependency, which locks service modules into a specific DLL version of the authentication DLL. Breaking the current dependency structure would mean a breaking change.

I'll keep this issue open as a feature request that we will implement when we bump our major version number (v2).