Powershell: How to automate either PowerShell or PowerShell Core for same machine

[msoliver]

Support Question

With the release of PowerShell Core, how can an application choose which version of Powershell (Powershell 5.x or PowerShell Core) is being called when it using hosting automation library (system.management.automation)? Something about the runspace that should be created? or maybe the connection info?

Official support

PowerShell Support Lifecycle

Community Resources

Slack and Discord Community Chat - Interactive chat with other PowerShell enthusiasts. Both Slack and Discord are bridged via a bot and can seamlessly talk to each other.
PowerShell.org Forum - Search or post new general PowerShell usage questions

[vexx32]

From what I know (others can correct me if I'm wrong), but if you're hosting PowerShell, I believe you'll be using whatever version matches the version of your NuGet package that you're pulling the libraries in with.

The PowerShellStandard.Library reference package, on the other hand, currently only works with 5.1 iirc.

[SeeminglyScience]

If you're hosting PowerShell, it's based on whatever runtime you compile for (sort of). If you're targeting netcoreapp, then you need to reference the PowerShell Core SDK. If you're compiling for net4xx then you need to reference either PowerShellStandard.Library (if they've fixed the hosting scenario) or the older reference library package that properly redirects to the GAC assembly.

Basically, if you're hosting PowerShell, you're starting whatever version you're bringing with you.

[mklement0]

Cross-posting from an answer to your question on Stack Overflow:

---

Here's an overview of the PowerShell SDK-related NuGet packages:^{Adapted from here.}

• Microsoft.PowerShell.5.ReferenceAssemblies - for building Windows PowerShell applications, based on the .NET Framework (Windows-only).

• Microsoft.PowerShell.SDK - for building PowerShell Core applications, based on .NET Core (cross-platform).

• PowerShellStandard.Library - for building _modules and hosts_ that are compatible with both Windows PowerShell and PowerShell Core (cross-platform) - but note:

  • "PowerShell Standard is a reference assembly that has been created to assist developers in creating modules and PowerShell hosts which will run on PowerShell. The reference assembly contains no actual implementation but rather will allow you to use only APIs that exist across different versions of PowerShell. This means that you still need to run within a PowerShell runtime."

  • For creating stand-alone applications, use one of the first two packages.

• System.Management.Automation - not recommended for direct use.

[msoliver]

Okay thanks - but one last question - what about the scenario in which my app is creating a remote runspace on another server? If that server has both variants of PowerShell - which one will execute?

[mklement0]

@msoliver: I'll respond on StackOverflow.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.