How to automate either PowerShell or PowerShell Core for same machine

Here’s an overview of the PowerShell SDK-related NuGet packages:Adapted from here.

Note: System.Management.Automation is not recommended for direct use.

  • To create stand-alone applications that host the PowerShell runtime in order to call PowerShell commands in-process:

    • Use Microsoft.PowerShell.5.ReferenceAssemblies for .NET Framework (Windows-only) applications using the legacy Windows PowerShell runtime.

    • Use Microsoft.PowerShell.SDK for (potentially cross-platform) .NET Core / 5+. applications using the PowerShell (Core) v6+ runtime.

      • To determine what specific .NET (Core) runtime a given package version must be combined with at a minimum, select the package version of interest on the linked page, expand the Dependencies section, and consult the first entry; e.g., for package version 7.2.0 the minimum required .NET (Core) runtime is net6.0.
  • To create assemblies that implement cmdlets / form part of modules for use in PowerShell or to create a PowerShell host:

    • Use PowerShellStandard.Library; it is compatible with both Windows PowerShell and PowerShell (Core) v6+, but note:

      • “[This] 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.

As for targeting a specific edition / version via remoting:

  • See this question and answer

  • Note that it covers remoting from the perspective of using PowerShell cmdlets, not the SDK, though you can always call the cmdlets via the SDK as well.


As Lee Daily points out in a comment, the edition-specific executable filenames are:

  • powershell.exeWindows PowerShell

  • pwsh.exe (Windows) / pwsh (Unix-like platforms) – PowerShell (Core) v6+

Leave a Comment