PowerShell vs. PowerShell Core, what you need to know
Microsoft announced the general availability of PowerShell Core 6.0 on January 10, 2018.
PowerShell Core is a new version of PowerShell, a command-line shell and scripting language that ships with Microsoft Windows.
The release of PowerShell Core increases the number of PowerShell editions to two. There is the decade-old PowerShell that is integrated into all recent versions of Microsoft's Windows operating system and the new PowerShell Core.
Microsoft sees PowerShell Core as an evolution of PowerShell. The former is available as a cross-platform application, the latter only for Windows.
The cross-platform nature of PowerShell Core means that scripts that you write will run on any supported operating system. You can write PowerShell Core scripts on Windows, and use them on supported Mac OS X or Linux devices. There are even experimental (unsupported) versions for ARM devices.
Microsoft works actively on PowerShell Core. PowerShell, on the other hand, is in a state that can best be compared to extended support for Windows versions. Microsoft has no plans to add features to PowerShell, but it will release critical bug fixes and security updates.
However, there are currently no plans to introduce new functionality to Windows PowerShell. This means that the risk of regression will be very low for Windows PowerShell, so you can count on it as a stable platform for your existing workloads.
PowerShell Core installs side by side on Windows. In short: PowerShell Core does not affect Windows PowerShell in any way on Windows devices.
PowerShell Core 6.0 is not as powerful as PowerShell 5.1. One core reason for that is that PowerShell has access to the .NET Framework and .NET Standard while PowerShell Core to the less-feature-rich .NET Core and .NET Standard.
Some technologies available to Windows PowerShell are not supported by .NET Core. Microsoft notes that some of the technologies may return in future releases but that this won't be the case for all of them.
The company mentions PowerShell Workflows, PowerShell Snap-ins, WMlv1 cmdlets and executing Desired State Configuration resources specifically. The Breaking changes for PowerShell 6.0 document offers further details.
The differences between PowerShell and PowerShell Core
|Versions||1.0 to 5.1||6.0|
|Platforms||Windows only (client and server)||Windows, Mac OS, Linux|
|Dependency||.Net Framework||.Net Core|
|Usage||Relies on .Net Framework runtime||Relies on .Net Core runtime|
|Launched as||powershell.exe||pwsh.exe (Windows), pwsh (Mac and Linux)|
|$PSVersionTable.PSEdition||Set to Desktop||Set to Core|
|Update policy||critical bug fixes only||all updates (features, bugs)|
PowerShell Core downloads
- PowerShell Core for Windows is available at this link.
- PowerShell Core for Mac OS X and Linux is available at this link.
Thanks for the article Martin. You forgot to mention that there is no PowerShell Core ISE any longer. To use it as such, you must use Visual Studio Code with the PowerShell Plugin, since VS Code works in all three OS’s.
Is that figure in the PowerShell 6.0 installation splash screen a woman or a man with long hair? :)
I hadn’t heard this was coming. I started using Powershell to automate stuff; Powershell can use most of .NET, without the cost, overhead, and learning curve of Visual Studio. I gained some expertise over the past five years. Now I feel like a dinosaur.
Time to research and reevaluate.
Just so you know, nothing you’ve learned so far is wasted. There are a few things in Powershell that won’t work in Powershell Core but other than that, it’s still the same language/platform. Your knowledge and expertise will transfer over as-is. Except, now you can use Powershell even if you are not using Windows.
You would need “Visual Studio Code” (VS Code) and NOT “Visual Studio”. The former is a different, simpler, more modern, open-source-(software-based) beast, with a vibrant plugin-ecosystem, aimed for more lightweight development: for example, powershell.
Genuinely one of the weirdest, scary-looking graphics I’ve ever seen in an installer wizard.
Exactly how I felt about it too.
I saw that graphic and was all wait, stop, this can’t be an official installer. What were they thinking?
I think it’s cool. Although not expected, but looks very nice :)
The question is, should we be helping Microsoft to extend their domain beyond their own (often frustrating) Operating Systems. I personally will not download and/or use this. If I need to write scripts for Linux, I’ll use my Linux machine. I’d rather see less Microsoft involvement in Linux than more personally. I am largely unimpressed with this company’s attitude towards its own users, and its ongoing purposeful ignorance of the amount of actual time/money this OS has lost for many users, with negligible benefits to balance that. F*ck Microsoft and all who sail in her.
Sigh. Its not like we don’t have enough programming and scripting languages as it is. Why will this be better than what we already have? What is the value add and who said we needed it?
On 2016-08-18 Microsoft said its customers say they need it. See
https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/. Fortunately my life is not so complicated to need it, and apparently neither is your life.
Yet another technology deprecated. They go gung-ho on Silverlight, Powershell, etc. Now Powershell will not have any advanced features so when Server whatever or Sharepoint whatever or SQL Server whatever get released with no features – no support there. So should we shift all development to .net core and Powershell core? Or will those two items quickly get replaced with something else?
Just so you know, nothing is being deprecated. There is a version of Powershell (and by extension, some features) being deprecated but Powershell itself isn’t being deprecated. In fact, I would expect they are going to invest more into Powershell going forward as they are all in on their class-platform push with Azure, .NET Core, VS Code, etc.
Another technology MS didn’t mention is PowerShell providers (see https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_providers?view=powershell-6&viewFallbackFrom=powershell-Microsoft.PowerShell.Core)
This means that other data sources besides those that MS decided to include can not be added. For example, including, but not limited to, all kinds of databases and yet unsupported file systems.
I’m having kind of a dÃ©ja vu similar to when Mono was initially released. If you want the full functionality, you can only get it on Windows.
Writing cross-platform applications and scripts requires a lot of extra effort. What is the point of doing so as long as you’re limited to the lowest common denominator of the framework/tool chain and not being able to extend the functionality when needed? I don’t get it.
JFYI: This article is very similar to yours
Basically the same screenshots and similar phrasing.
Is some trepidation regarding this direction chosen for PowerShell, and evolution into PowerShell Core wrong?
Powershell is genuinely growing into an effective & accessible platform, bringing automation & easier understanding of administration of all things Windows to the masses. (and full audience saturation & adoption takes time, discovery lag. So to the people who design it and are like “its boring, it needs something new” may be pretty far in front of the curve).
While enabling (limited) cross-platform scripting is a technological achievement (braggable, but arcanely), this probably isn’t going to be leveraged (or even perhaps understood) by the single platform Windows-centric developers (what percentage of PowerShell adopters would leverage the poly-platform capabilities? Many of us, due to corporate restrictions aren’t even allowed to tie two windows machines together, let alone two operating systems).
The idea that Windows PowerShell would cease evolution in order to make this commitment strikes as premature, as PowerShell in its current form has opened a world of beautiful potential, and the ISE is a wonderful accessory. Moving from the practical back to the conceptual, in hopes that the conceptual eventually returns the journey back to practical again, is a worrisome leap.