PowerShell/PowerShellStandard

PowerShell.Create() returns null

patware opened this issue · 7 comments

.Net Standard 2.0
PowerShellStandard.Library Version 5.1.0

    public class Class1
    {
        public string Foo()
        {
            using(var ps = PowerShell.Create())
            {
                ps.AddScript("'Hi'");
                var result = ps.Invoke();

                return result.ToString();
            }
        }
    }

The PowerShell.Create() returns null.
Tried also with PowerShell.Create(RunspaceMode.NewRunspace), same result.

How are you using this library? In a standalone application or within a PowerShell session?

Standalone application.

Tried 4 scenarios:

  1. .Net Core Console App with code above with basically the code above in the static void Main - FAIL
  2. .Net Core Console App calling a .Net Standard with the code above - FAIL
  3. .Net Framework Console App with code above with basically the code above in the static void Main - PASS
  4. .Net Framework Console App calling a .Net Standard with the code above - PASS

Details:

  • CoreConsoleApp: .Net Core 2.2
  • FrameworkConsoleApp: 4.7.2
  • SharedClassLibrary: .Net Standard 2.0

PowershellHosting.zip

This is a shim library that’s only made to run within PowerShell itself. It’s used for create cross-platform/cross-powershell version cmdlets and such.

What you want to leverage is the PowerShell SDK:
https://www.nuget.org/packages/Microsoft.PowerShell.SDK/7.0.0-preview.1

This has the actual PowerShell bits inside and PowerShell.Create will work as expected.

Understood...

Just curious... Is the following statement from the Readme still valid:

PowerShell Standard.Library Version 5.1
This allows you to create PowerShell modules and host which will run on PowerShell Version 5.1 and later including PowerShellCore

It’s technically true… with a typo. You can write a PowerShell host that will run on PowerShell 5.1 and later. That’s what we do in https://github.com/PowerShell/PowerShellEditorServices

We’re so good at overloading terms…

I can update the doc to be more explicit.

I’ve opened #64 with an explicit note on not using this for standalone apps