vscode-powershell: Scripts using PNP.PowerShell do not work in VSCode

Re-reading through this whole issue, please correct me if I’m wrong, but I believe these problems are only occurring with Windows PowerShell (e.g. PowerShell 5.1), not PowerShell Core (e.g. PowerShell 7). This makes some sense too given that it’s an assembly loading issue and the ALCs used to separate dependencies from each other are no present in .NET Framework (which Windows PowerShell is bound to). So Windows PowerShell is loading the library from the GAC, and then when PnP.PowerShell needs a different version of the library, it cannot get it due to the fundamental nature of .NET Framework’s assembly loading logic and Global Assembly Cache.

Because VS Code PowerShell Editor already loaded their dependencies and has a ALC which does not check the requested dependency’s version, it will return the already loaded version. So in the case of the example, when our code at some point requests Microsoft.BCL.AsyncInterfaces 1.1.1, we get 5.0.0.

This is almost correct, except we tested that in https://github.com/PowerShell/vscode-powershell/issues/3510#issuecomment-904998935. This points to the issue being similar, but what I just outlined: the ALC logic is being avoided entirely due to this being an issue with Windows PowerShell 5.1 which uses .NET Framework and the GAC. The assembly resolve event handler in Windows PowerShell loads a version of Microsoft.BCL.AsyncInterfaces, and then because of the GAC, this is later returned to PnP.PowerShell. I’m unsure if there’s a way around this, because the way around it is to use Assembly Load Contexts, but that’s unavailable in this scenario.

@andschwa - Yes, we are going to bump the MSAL.NET to the latest version , mostly 4.49 as part of the update to v2. Hopefully, will fix things.

We have discussed this, but turns out its very complex to resolve, if possible at all. In all honesty, with everything we have open and the limited resources we have contributing to the code at the moment, I would not count on this to be fixed soon if at all.

You can use a regular pwsh terminal in VS Code, just not the “Extension Terminal.” Click the + button to spawn a new terminal in the pane.

Thank you, this workaround works for me

You can use a regular pwsh terminal in VS Code, just not the “Extension Terminal.” Click the + button to spawn a new terminal in the pane.

I think you are quite close to the issue @andschwa, the problem occurs, if shared dependencies exist in s_psHome which are requested. Then they are returned / loaded from PnP’s ALC even if the requested Version does not match. I’m not so sure, but a Version-Check as in PsesLoadContext could do the trick. For dependencies not existing in s_psHome the code is partially working, they are loaded from the modules-directory but could have the wrong version as well.

Oh, ohhh, oh! @gautamdsheth I was finding PnP.PowerShell’s ALC to link here again, which is nearly an exact copy of the example from Rob that @JustinGrote just shared…and with a fresh set of eyes and a cup of coffee in me, I think I spied the issue:

        protected override Assembly Load(AssemblyName assemblyName)
        {
            string assemblyFileName = $"{assemblyName.Name}.dll";

            // Make sure we allow other common PowerShell dependencies to be loaded by PowerShell
            // But specifically exclude Microsoft.ApplicationInsightssince we want to use a different version here
            if (!assemblyName.Name.Equals("Microsoft.ApplicationInsights", StringComparison.OrdinalIgnoreCase))
            {
                string psHomeAsmPath = Path.Join(s_psHome, assemblyFileName);
                if (File.Exists(psHomeAsmPath))
                {
                    // With this API, returning null means nothing is loaded
                    return null;
                }
            }

            // Now try to load the assembly from the dependency directory
            string dependencyAsmPath = Path.Join(_dependencyDirPath, assemblyFileName);
            if (File.Exists(dependencyAsmPath))
            {
                return LoadFromAssemblyPath(dependencyAsmPath);
            }

            return null;
        }

My understanding of this is that Microsoft.ApplicationInsights is the only dependency being loaded from the module’s dependency directory path, everything else (such as Microsoft.Identity.Client, the problem) is being loaded from the shared path of PowerShell (or from a previous resolution).

Just dumping some info here, I can confirm that PnP.PowerShell (both 2.x and 1.x) depend on older versions of Microsoft.Identity.Client than requested by ExchangeOnlineManagement and MicrosoftTeams modules. And so far as I’ve been able to dig, none of PowerShell Editor Services, Secret Management, nor Secret Store depend on this module.

@gautamdsheth is there a way to get PnP.PowerShell to accept 4.0 and up? I think you might have some “must be this version” logic that’s causing the 4.29 from Teams and the 4.44 from Exchange to be rejected, but I’m willing to bet that if it did allow it to be used, it might just work fine. I think that’s something to do with bindingRedirects right?

@JustinGrote, this is unfortunately out of my hands. We’re waiting on a fix from the PnP.PowerShell team. @KoenZomers said they will have Erwin van Hunen take a look “soon.”

@KoenZomers the problem is not per-se with PnP.PowerShell but with the ALC that resolves the DLL’s. There is a conflict when PowerShell Editor Services (Integrated Terminal) and the 3rd Party Package (PnP.PowerShell or my Repro Package (which includes EntityFramework Core as dependency)) are targeting other version of DLL’s and both are using their own ALC.

For example:

• VS Code Editor Services is depending on Microsoft.Bcl.AsyncInterfaces version 5.0.0
• 3rd-party Package is depending on Microsoft.Bcl.AsyncInterfaces with version 1.1.1

Because VS Code PowerShell Editor already loaded their dependencies and has a ALC which does not check the requested dependency’s version, it will return the already loaded version. So in the case of the example, when our code at some point requests Microsoft.BCL.AsyncInterfaces 1.1.1, we get 5.0.0.

In PnP.PowerShell, the dependency versions are most of the time equal to VS Code PowerShell Editor Services. So in fact, you don’t see this exception very often.

cc @andschwa

I’ve added it to the list to discuss with him during our next meeting. Can someone that can reproduce this issue also try it with PnP PowerShell 1.6.0? And also with the latest prerelease build? Perhaps through narrowing down exactly in which version something changed we can look at the differences done in that release and figure it out.

This goes beyond my knowledge. We would need Erwin van Hunen to have a look at this, but he’s currently overly occupied so that’s likely going to take a while.

@rjmholt after following up your answer in the PowerShell Discord Server I created a “not-so” minimal repro example. https://github.com/lucahost/PSES-ALC-Repro as mentioned in the .\Run.ps1 script, running this with PowerShell 5.1 should work where running it with PSES will result in Errors If I can provide anything more or something is not working I’m here to assist.

If you attach VisualStudio to the PowerShell Process (Set a Breakpoint before Import-Module) and go to Debug -> Windows -> Modules, you’ll see from where the Assemblies are loaded.