Scripts using PNP.PowerShell do not work in VSCode #3510
Comments
ghost
added
the
|
Can you provide the output of |
|
|
Maybe a typo in a configuration ? |
|
Can you confirm that @rjmholt Look at the accepted answer in https://docs.microsoft.com/en-us/answers/questions/302548/jsonserializer-throws-exception-in-xamarinios.html, very curious. |
|
This is the result of $PSVersionTable in PowerShell Integrated Console of vscode: Name Value PSVersion 5.1.19041.1023 |
|
Maybe same problem here: |
|
I have removed module "PNP.PowerShell" in Version 1.7.0 and installed this module in version 1.5.0. Conclusion: But strange anyway: The exception is only thrown when running CMDLets in VSCode-PowerShell. I will post an issue in PNP.PowerShell. |
|
Going to reopen the issue here since it's quite possible this is at least partially an issue in PSES |
|
Just for reference, the module sources: https://github.com/pnp/powershell |
|
@Tom-CK Can you check if this works with PowerShell 7? We have a theory right now... |
|
Hey @erwinvanhunen, this bug appears between 1.5.0 and 1.7.0, and we think it was the introduction of your own ALC that may have caused this unfortunate interaction. PSES's assembly load logic when running with Windows PowerShell (so full .NET) does not check for the assembly version, it only resolves by name, and we think that's the issue. Since PSES has its own resolve assembly event, the one in pnp/powershell@fd65170#diff-05a628297ec69a1e93f2c84d148c6fac638d6499eda9b04d32a914b628fbe660 isn't being fired. We fear that a lot might break if we change our assembly loader to start checking for name + version. 🧐 |
andyleejordan
added
Area-Extension Terminal
and removed
Needs: Triage
|
It looks like PnP also does some dependency wrangling and registers their own assembly resolve event, but neither of us checks the required assembly version. I've had a go implementing that. Give the extension here a try and let me know what happens. |
|
I loaded the zip, disabled the original powershell extension and it did not fix the issue for me. My issue might be different because so far I am only having issues using the "Teams" commands. The SharePoint commands I have used so far have not caused me any issue. The return should have been a list of 20-30 sites, I get nothing in the integrated console. |
Well, that's good to know. 🤔 |
Ok that's much stranger than getting an exception, and harder to debug unfortunately |
Here is the error when I try to target a specific site as this actually gives an error. |
|
Sorry for my late reply, I was on holidays for some days: Please remind:
|
For me the error only exists in the "Powershell Integrated Console" terminal, switching terminals to "Powershell" I can run the commands and they work. Yes 1.5.0 is the last working version for this issue. |
|
Using Windows, PowerShell 7.3.2 and Visual Studio Code 1.74.3 and PowerShell for Visual Studio Code v2022.11.0 and also tried v2023.1.0. PnP.PowerShell 1.12.0. |
|
I will try to spend the next community day (Monday) looking at this again, though I'm not hopeful. I think it's on PnP.PowerShell to either implement or fix their own Assembly Load Context. |
|
@andschwa - thank you taking the time to investigate it. We have launched a new 2.x nightly which has dropped support PS5 and is based completely on .NET 6 , maybe it can help ? The nightly builds are available via PSGallery and using -Allowprerelease parameter to install the module |
|
@gautamdsheth that sounds super promising! |
|
@gautamdsheth have you seen pnp/powershell#1814 (reply in thread)? I'm going to see if we load |
|
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
|
|
Considering people are having issues with PowerShell 7 and only in the Extension Terminal, where we have an ALC, I'm thinking Rob may have been onto something when he surmised that it's because we don't check assembly versions in PSES. But this is far outside my expertise, I'll chat with @SeeminglyScience. |
|
@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. |
Hello @andschwa & @gautamdsheth I hope version 2 will be able solve this problem... It's really annoying to have module cohabitation problems because of this DLL. |
|
Since you now have a .net 6 only version, you really should look into using assemblyLoadContext to abstract your dependencies from the PowerShell shared assembly space to avoid this problem. EDIT: Sorry this was directed at PnP development, I forgot what repo I was in, oops. |
|
@JustinGrote thing is, they are using an ALC. Somehow the combination of being loaded in the extension terminal where PSES is using an ALC breaks their ALC. Yes, it should "just be working" because of module dependency isolation...but for reasons I don't know where to begin to find out, it's not. |
|
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 |
|
I think you are quite close to the issue @andschwa, the problem occurs, if shared dependencies exist in |
|
This issue has been marked as external. It has been automatically closed for housekeeping purposes. |
|
@lucahost It's actually worse than this. The |
|
any suggestions or workarounds for this? |
|
You can use a regular |
Thank you, this workaround works for me |
and others
Prerequisites
Summary
I've installed PNP.PowerShell-Module Version 1.7.0.
When working within a normal PowerShell, all CMDLets work fine - for example running "Get-PBPListItem" returns the expected items.
When I work in VSCode with installed PowerShell Extension (v 2021.8.0), ALL PNP-PowerShell CMDLets throw an exception (TargetInvocationException).
This used to work perfect earlier ....
PowerShell Version
Visual Studio Code Version
Extension Version
Steps to Reproduce
Visuals
Logs
No response
The text was updated successfully, but these errors were encountered: