Skip to content

Variable defined in InitialSessionState is not available in scriptblock originating from another runspace #7593

Closed

Description

@alx9r

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

Activity

  1. BrucePay commented on Aug 22, 2018

    @BrucePay
    Collaborator

    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.

  2. lzybkr commented on Aug 22, 2018

    @lzybkr
    Contributor

    Bruce Payette (@BrucePay) - that's mostly right, but scriptblocks created via [ScriptBlock]::Create are not bound to a runspace until they are first invoked.

  3. added
    WG-Enginecore PowerShell engine, interpreter, and runtime
    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif
    on Aug 22, 2018
  4. BrucePay commented on Aug 23, 2018

    @BrucePay
    Collaborator

    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.

  5. lzybkr commented on Aug 23, 2018

    @lzybkr
    Contributor

    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.

  6. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  7. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  8. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  9. microsoft-github-policy-service commented on Nov 23, 2023

    @microsoft-github-policy-service
    Contributor

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-No ActivityIssue has had no activity for 6 months or moreWG-Enginecore PowerShell engine, interpreter, and runtime

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions