You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Scripts using PNP.PowerShell do not work in VSCode #3510
I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
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).
$error[0] | fl * -force
writeErrorStream : True
PSMessageDetails :
Exception : System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.MissingMethodException:
Methode nicht gefunden: "Int32 System.Text.Encodings.Web.TextEncoder.FindFirstCharacterToEncodeUtf8(System.ReadOnlySpan`1<Byte>)".
bei System.Text.Json.JsonWriterHelper.NeedsEscaping(ReadOnlySpan`1 value, JavaScriptEncoder encoder)
bei System.Text.Json.JsonEncodedText.EncodeHelper(ReadOnlySpan`1 utf8Value, JavaScriptEncoder encoder)
bei System.Text.Json.JsonPropertyInfo.DeterminePropertyName()
bei System.Text.Json.JsonPropertyInfo.GetPolicies()
bei System.Text.Json.JsonClassInfo.CreateProperty(Type declaredPropertyType, Type runtimePropertyType, Type
implementedPropertyType, PropertyInfo propertyInfo, Type parentClassType, JsonConverter converter, JsonSerializerOptions options)
bei System.Text.Json.JsonClassInfo.AddProperty(Type propertyType, PropertyInfo propertyInfo, Type classType, JsonSerializerOptions
options)
bei System.Text.Json.JsonClassInfo..ctor(Type type, JsonSerializerOptions options)
bei System.Text.Json.JsonSerializerOptions.GetOrAddClass(Type classType)
bei System.Text.Json.JsonSerializer.ReadCore(Type returnType, JsonSerializerOptions options, Utf8JsonReader& reader)
bei System.Text.Json.JsonSerializer.Deserialize(String json, Type returnType, JsonSerializerOptions options)
bei System.Text.Json.JsonSerializer.Deserialize[TValue](String json, JsonSerializerOptions options)
bei PnP.Framework.Utilities.TokenHelper.GetMetadataDocument(String realm)
bei PnP.Framework.Utilities.TokenHelper.GetStsUrl(String realm)
bei PnP.Framework.Utilities.TokenHelper.GetAppOnlyAccessToken(String targetPrincipalName, String targetHost, String targetRealm)
bei PnP.Framework.Utilities.ACSTokenGenerator.GetToken(Uri siteUrl)
bei PnP.Framework.AuthenticationManager.<>c__DisplayClass75_0.<GetAccessTokenContext>b__0(Object sender, WebRequestEventArgs args)
bei Microsoft.SharePoint.Client.ClientRuntimeContext.OnExecutingWebRequest(WebRequestEventArgs args)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture)
bei Microsoft.SharePoint.Client.ClientContextExtensions.<>c__DisplayClass10_0.<Clone>b__0(Object oSender, WebRequestEventArgs
webRequestEventArgs)
bei System.EventHandler`1.Invoke(Object sender, TEventArgs e)
bei Microsoft.SharePoint.Client.ClientRuntimeContext.OnExecutingWebRequest(WebRequestEventArgs args)
bei Microsoft.SharePoint.Client.ClientContext.GetWebRequestExecutor()
bei Microsoft.SharePoint.Client.ClientContext.<GetFormDigestInfoPrivateAsync>d__37.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Microsoft.SharePoint.Client.ClientContext.<EnsureFormDigestAsync>d__36.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Microsoft.SharePoint.Client.ClientContext.<ExecuteQueryAsync>d__28.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei Microsoft.SharePoint.Client.ClientContextExtensions.<ExecuteQueryImplementation>d__6.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Microsoft.SharePoint.Client.ClientContextExtensions.ExecuteQueryRetry(ClientRuntimeContext clientContext, Int32 retryCount,
String userAgent)
bei PnP.PowerShell.Commands.PnPWebCmdlet.GetWeb()
bei PnP.PowerShell.Commands.Lists.GetListItem.ExecuteCmdlet()
bei PnP.PowerShell.Commands.PnPSharePointCmdlet.ProcessRecord()
TargetObject :
CategoryInfo : WriteError: (:) [Get-PnPListItem], TargetInvocationException
FullyQualifiedErrorId : EXCEPTION,PnP.PowerShell.Commands.Lists.GetListItem
ErrorDetails : Ein Aufrufziel hat einen Ausnahmefehler verursacht.
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : bei <ScriptBlock>, <Keine Datei>: Zeile 1
PipelineIterationInfo : {0, 1}
Can you confirm that $PSVersion from the integrated console session itself? I'm wondering if maybe you're in PowerShell 7 there...(I mean, it should still work, but it would help narrow things down).
I have removed module "PNP.PowerShell" in Version 1.7.0 and installed this module in version 1.5.0.
The error went away.
Then I updated module "PNP.PowerShell" back to Version 1.7.0 - the error was there again.
This can be reproduced.
Conclusion:
The problem must have something to do with module PNP.PowerShell Version 1.7.0.
But strange anyway: The exception is only thrown when running CMDLets in VSCode-PowerShell.
Hey Erwin van Hunen (@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. 🧐
protectedoverrideAssemblyLoad(AssemblyNameassemblyName){stringassemblyFileName=$"{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 hereif(!assemblyName.Name.Equals("Microsoft.ApplicationInsights",StringComparison.OrdinalIgnoreCase)){stringpsHomeAsmPath=Path.Join(s_psHome,assemblyFileName);if(File.Exists(psHomeAsmPath)){// With this API, returning null means nothing is loadedreturnnull;}}// Now try to load the assembly from the dependency directorystringdependencyAsmPath=Path.Join(_dependencyDirPath,assemblyFileName);if(File.Exists(dependencyAsmPath)){returnLoadFromAssemblyPath(dependencyAsmPath);}returnnull;}
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).
I think you are quite close to the issue Andy Jordan (@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.
Luca Hostettler (@lucahost)I think you are right and that it's the version check that's missing, presumably causing an the older version of Microsoft.Identity.Client shipped with PnP.PowerShell to be returned as resolved even when the requestor requires a newer version.
It's actually worse than this. The AssemblyLoadContext as implemented in PnP.PowerShell is only isolating Microsoft.ApplicationInsights, and PnP.PowerShell has a lot more dependencies (namely Microsoft.Identity.Client) that conflict and need to be isolated in the same manner.
any suggestions or workarounds for this?
This issue seems to be going for a years and I stucked with my development with this
I can do nothing in VS Code which is the one IDE I can use for Powershell 7.x
I have written a descriptive issue title.[x] I have searched all issues to ensure it has not already been reported.[x] I have read the troubleshooting guide.[x] I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
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).
Activity
rjmholt commentedon Aug 17, 2021
Can you provide the output of
$error[0] | fl * -forceafter the error occurs?Tom-CK commentedon Aug 17, 2021
Tom-CK commentedon Aug 17, 2021
Maybe a typo in a configuration ?
I did not change anything in config.
andyleejordan commentedon Aug 17, 2021
Can you confirm that
$PSVersionfrom the integrated console session itself? I'm wondering if maybe you're in PowerShell 7 there...(I mean, it should still work, but it would help narrow things down).Rob Holt (@rjmholt) Look at the accepted answer in https://docs.microsoft.com/en-us/answers/questions/302548/jsonserializer-throws-exception-in-xamarinios.html, very curious.
Tom-CK commentedon Aug 18, 2021
This is the result of $PSVersionTable in PowerShell Integrated Console of vscode:
Name Value
PSVersion 5.1.19041.1023
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.1023
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Tom-CK commentedon Aug 18, 2021
Maybe same problem here:
pnp/powershell#727
Tom-CK commentedon Aug 18, 2021
I have removed module "PNP.PowerShell" in Version 1.7.0 and installed this module in version 1.5.0.
The error went away.
Then I updated module "PNP.PowerShell" back to Version 1.7.0 - the error was there again.
This can be reproduced.
Conclusion:
The problem must have something to do with module PNP.PowerShell Version 1.7.0.
But strange anyway: The exception is only thrown when running CMDLets in VSCode-PowerShell.
I will post an issue in PNP.PowerShell.
rjmholt commentedon Aug 18, 2021
Going to reopen the issue here since it's quite possible this is at least partially an issue in PSES
andyleejordan commentedon Aug 24, 2021
Just for reference, the module sources: https://github.com/pnp/powershell
andyleejordan commentedon Aug 24, 2021
Tom-CK Can you check if this works with PowerShell 7? We have a theory right now...
andyleejordan commentedon Aug 24, 2021
Hey Erwin van Hunen (@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. 🧐
67 remaining items
andyleejordan commentedon Feb 21, 2023
Oh, ohhh, oh! Gautam Sheth (@gautamdsheth) I was finding PnP.PowerShell's ALC to link here again, which is nearly an exact copy of the example from Rob that Justin Grote (@JustinGrote) just shared...and with a fresh set of eyes and a cup of coffee in me, I think I spied the issue:
My understanding of this is that
Microsoft.ApplicationInsightsis the only dependency being loaded from the module's dependency directory path, everything else (such asMicrosoft.Identity.Client, the problem) is being loaded from the shared path of PowerShell (or from a previous resolution).andyleejordan commentedon Feb 22, 2023
Luca Hostettler (@lucahost) and Gautam Sheth (@gautamdsheth) check out what we have here: https://github.com/PowerShell/PowerShellEditorServices/blob/main/src/PowerShellEditorServices.Hosting/Internal/PsesLoadContext.cs
lucahost commentedon Feb 22, 2023
I think you are quite close to the issue Andy Jordan (@andschwa), the problem occurs, if shared dependencies exist in
s_psHomewhich 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_psHomethe code is partially working, they are loaded from the modules-directory but could have the wrong version as well.andyleejordan commentedon Jun 8, 2023
Luca Hostettler (@lucahost)
I think you are right and that it's the version check that's missing, presumably causing an the older version ofMicrosoft.Identity.Clientshipped with PnP.PowerShell to be returned as resolved even when the requestor requires a newer version.It's actually worse than this. The
AssemblyLoadContextas implemented in PnP.PowerShell is only isolatingMicrosoft.ApplicationInsights, and PnP.PowerShell has a lot more dependencies (namelyMicrosoft.Identity.Client) that conflict and need to be isolated in the same manner.pnp/powershell#488 (comment)
all2001 commentedon Oct 19, 2023
any suggestions or workarounds for this?
This issue seems to be going for a years and I stucked with my development with this
I can do nothing in VS Code which is the one IDE I can use for Powershell 7.x
andyleejordan commentedon Oct 19, 2023
You can use a regular
pwshterminal in VS Code, just not the "Extension Terminal." Click the+button to spawn a new terminal in the pane.all2001 commentedon Oct 20, 2023
Thank you, this workaround works for me
SamErde commentedon Mar 12, 2026
I just released v1.0 of my DLL Pickle module that prevents most cases of these DLL version conflicts. Please try it out and let me know your results!
andyleejordan commentedon Mar 14, 2026
Sam Erde (@SamErde) that looks really ingenious...nice work.
SamErde commentedon Mar 14, 2026
Thank you very much, Andy Jordan (@andyleejordan)! I just need to sort out an issue with talk of the libraries in Windows PowerShell 5.1 still.
kakareikaua-tech commentedon Sep 17, 2026