• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Think PowerShell

Think PowerShell

PowerShell for IT Pros

  • About
    • Who I Am
    • Why I Blog
    • Privacy Policy
  • Resources
    • More PowerShell Sites
    • Post Series Index
  • Get Help
  • Show Search
Hide Search

Decision to Switch to PowerShell Core (pwsh)

Aaron Rothstein · February 25, 2019 · Leave a Comment

Slightly different icon of PowerShell Core.

The decision is clear: it is time to switch to PowerShell Core.

A lot has happened since the last time I published a post (November 2017), including the release of PowerShell Core 6.0 in January 2018.

PowerShell Core 6.0 History

PowerShell Core 6.0 introduced a major break from Windows PowerShell which we had been using. Some of the big differences were:

  • PowerShell Core runs on .NET Core; Windows PowerShell runs on .NET Framework. Because of this, PowerShell Core did not have all of the cmdlets of Windows PowerShell.
  • PowerShell Core is cross-platform (Windows, macOS, Linux); Windows PowerShell is Windows only.
  • PowerShell Core’s binary name is pwsh.exe, so it can run side-by-side with Windows PowerShell (powershell.exe).

PowerShell Core 6.0 could not do everything Windows PowerShell was capable of, but over the course of 2018 it saw two updates (6.1 and 6.2) which helped close the functionality gap. More on that later.

A major factor in my decision to start using PowerShell Core by default is Microsoft has essentially said Windows PowerShell, outside of security fixes and bug fixes, will not be actively developed. Translation: PowerShell Core is the long-term future of PowerShell.

Windows Compatibility Module makes PowerShell Core feasible for Windows

Each update to PowerShell Core has added more cmdlets to bring it closer to parity with Windows PowerShell, but it is a long road and isn’t there yet. That is why in November 2018 Microsoft announced the release of the Windows Compatibility Module.

The purpose of this module is to give PowerShell Core 6 scripts access Windows PowerShell modules that are not yet native to PowerShell Core. It works through implicit remoting, meaning you are transparently PowerShell remoting to localhost in order to leverage Windows PowerShell.

Reasons for switching to PowerShell Core

I am making the commitment to switch to PowerShell Core as by preferred PowerShell engine. Here is why:

  • Cross-platform – In addition to Windows, I can leverage PowerShell skills on macOS and Linux.
  • PowerShell Core can be included and used in containers.
  • Microsoft’s long-term play for PowerShell is PowerShell Core, not Windows PowerShell. I want to begin leveraging the technology with a future.

Next Steps

All new posts (of which I plan on getting back into a regular cadence of writing) will be scoped to use PowerShell Core. If I encounter situations where I cannot use Core, I will explain why I could not use it and had to fall back to Windows PowerShell.

In my next post, I will cover getting started with PowerShell Core on Windows.

General Core

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Aaron

Think PowerShell

Copyright © 2025 · Monochrome Pro on Genesis Framework · WordPress · Log in