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
Variable defined in InitialSessionState is not available in scriptblock originating from another runspace #7593
This came up when experimenting with Jason Shirk (@lzybkr)'s workaround for #7530. In short, I'm using the ScriptBlock (not just its string representation) from one runspace in another so that file position information is correctly reported when an error is encountered.
Steps to reproduce
$scriptblock= {
"a in dot-invoked scriptblock: $a"
}
$powershell= [powershell]::Create().
AddScript({
"a in outer scriptblock: $a".$args[0]
}).
AddArgument($scriptblock)
$initialSessionState= [initialsessionstate]::CreateDefault()
$initialSessionState.Variables.Add(
[System.Management.Automation.Runspaces.SessionStateVariableEntry]::new(
'a',1,''
)
)
$runspace= [runspacefactory]::CreateRunspace($initialSessionState)
$runspace.Open()
$powershell.Runspace=$runspace$powershell.Invoke()
Expected behavior
a in outer scriptblock: 1
a in dot-invoked scriptblock: 1
Actual behavior
a in outer scriptblock: 1
a in dot-invoked scriptblock:
Environment data
>$PSVersionTable
Name Value
---------
PSVersion 6.1.0-preview.4
PSEdition Core
GitCommitId 6.1.0-preview.4
OS Microsoft Windows 6.3.9600
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Scriptblocks are afinitized to the runspace where they were created. Basically,the internal session state pointer for the scriptblock still points to the original runspace. If you create the scriptblock on a thread that doesn't have a runspace associated with it (i.e. from a C# host app) then this might work but there's no way you can do that from within PowerShell.
Bruce Payette (@BrucePay) - that's mostly right, but scriptblocks created via [ScriptBlock]::Create are not bound to a runspace until they are first invoked.
Jason Shirk (@lzybkr) Right but then you lose all of the source context which was the whole point of the exercise. Now If we made the overload of [scriptblock]::Create() that takes an AST public, then everything should work.
The binding to the runspace happens here - and you can see it is not part of ScriptBlock.Create, though that line could maybe be moved into ScriptBlock.Create.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
Activity
BrucePay commentedon Aug 22, 2018
Scriptblocks are afinitized to the runspace where they were created. Basically,the internal session state pointer for the scriptblock still points to the original runspace. If you create the scriptblock on a thread that doesn't have a runspace associated with it (i.e. from a C# host app) then this might work but there's no way you can do that from within PowerShell.
lzybkr commentedon Aug 22, 2018
Bruce Payette (@BrucePay) - that's mostly right, but scriptblocks created via
[ScriptBlock]::Createare not bound to a runspace until they are first invoked.BrucePay commentedon Aug 23, 2018
Jason Shirk (@lzybkr) Right but then you lose all of the source context which was the whole point of the exercise. Now If we made the overload of
[scriptblock]::Create()that takes an AST public, then everything should work.lzybkr commentedon Aug 23, 2018
The binding to the runspace happens here - and you can see it is not part of
ScriptBlock.Create, though that line could maybe be moved intoScriptBlock.Create.microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.