Microsoft.Identity.Client version and dependency design

[PrzemyslawKlys]

Verified issue does not already exist?

I have searched and found no existing issue

What error did you receive?

I'm a bit tired of fighting Microsoft.Identity.Client dependency hell alone so I thought I would reach out to multiple module owners to try and establish some common ground around it.

On my personal machine:

On my work server:

Now, I do have couple of older version of the same libraries and that is fine, but I wanted to show the problem how things look.

It seems Microsoft.Graph.* is eager to update to newest versions, Exchange Online Mananement stays on the very end of it, MSAL.PS, well it's not really maintained anymore, and then Pnp.PowerShell module has it's own decision on version.

DBATools on the other end uses different version for Desktop vs Core version, as did my own Mailozaurr few versions back.

While I have added some handling of that specific dependency in my Mailozaurr module, I guess the best idea would be to follow Microsoft.Graph and when they release new version, check what version they have and update or maybe agree that we all should stop on some version and keep using it until it's critical to update.

Depending on which module gets imported first the other will most likely fail.

I know PS 7 brings ALC improvements, but no one has really implemented it as it's not super easy,

In Mailozaurr I'm having custom OnImportAndRemove way where it kind of forcing usage of my own libraries versions or ignores it if it can't do something

• https://github.com/EvotecIT/Mailozaurr/blob/ReworkDLL/Sources/Mailozaurr/OnImportAndRemove.cs
• https://github.com/EvotecIT/Mailozaurr/blob/ReworkDLL/Mailozaurr.psm1

Would you be up to implementing some sort of unification across powershell modules for this?

Steps to Reproduce

$Folder = $Env:PSModulePath -split ";"
foreach ($F in $Folder) {
    if (Test-Path -Path $F) {
        Get-ChildItem -LiteralPath $F -Recurse -Filter "*.dll" | ForEach-Object {
            if ($_.Name -like "Microsoft.Identity.Client.dll") {
                [PSCustomObject] @{
                    Name    = $_.FullName
                    Version = $_.VersionInfo.FileVersion
                }
            }
        }
    }
}

[System.AppDomain]::CurrentDomain.GetAssemblies() | Where { $_.Location -like "*Microsoft.Iden*" } | fl *

Please confirm that you are running the most recent version of dbatools

I try to. But it affects all versions

Other details or mentions

No response

What PowerShell host was used when producing this error

PowerShell Core (pwsh.exe), Windows PowerShell (powershell.exe), VS Code (terminal), VS Code (integrated terminal)

PowerShell Host Version

Name Value

---

PSVersion 7.4.2
PSEdition Core
GitCommitId 7.4.2
OS Microsoft Windows 10.0.17763
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

SQL Server Edition and Build number

Not related

.NET Framework Version

Not related

[potatoqualitee]

I think I just saw another issue that may be related to this. I had to update Microsoft.Identity recently due to a CVE in SqlClient.

Unfortunately, I am very very limited on my ability to troubleshoot DLLs. Perhaps @FriedrichWeinmann or @StartAutomating have some ideas? I believe James was trying to address this in one of his modules to make things like this easier.

[PrzemyslawKlys]

To address this for PS 7 you would need to implement what jborean93 shows:

• https://github.com/jborean93/PowerShell-ALC

It allows DLL to not get into conflict, but implementing this is not trivial, especially for large module like this. And you still have to take care of PS 5.1 conflicts the old way.

I am mostly proposing to upgrade the version to non-vurnable (which is even bad in Microsoft.Graph as it uses 4.60.1) and follow Microsoft.Graph with it's version.

I know Microsoft.Graph releases new version every 2 weeks, so it's not great, but this is the only thing I can think of. If they upgrade to 4.60.3, we try to follow and keep it in sync. If new version is out, but Microsoft.Graph doesn't upgrade, we keep it the same.

Right now I have to resort to drastic fix, by replacing DLLs myself all over the place to avoid conflicts so all the DLL version matches, but that goes a bit too far as I am modifying someone else's libraries.

[potatoqualitee]

Thanks for the explanation.

There's another CVE that I'm missing? I just got a scan and passed. I don't believe it's reasonable to update the library every 2 weeks, so that cannot be a solution, unfortunately.

[PrzemyslawKlys]

As you can see on nuget.org it shows which versions are affected so the one you use 4.56 has vulnerabilities, you also use 4.53 which is also marked as problematic.

I guess 2 weeks is nuts, but it only would matter if the DLL would be updated. Most of the processes I have are automated to republish so for me it's not a big deal.