- different editions of PowerShell
- PowerShell’s relationship to .NET Core and .NET Standard
- the future of PowerShell
- when you might expect to start taking a dependency on PowerShell Core 6.0 in production
PowerShell Editions
There are two editions of PowerShell:
Windows PowerShell is the edition of PowerShell built on top of .NET Framework
(sometimes referred to colloquially as “FullCLR”):
- This is the PowerShell that has been in widespread use for the last ~10 years.
- Because of it’s dependency on the .NET Framework, Windows PowerShell is only available on Windows (hence the name).
- The released versions of Windows PowerShell include 1.0, 2.0, 3.0, 4.0, 5.0, and 5.1.
- Windows PowerShell is available as a built-in component in Windows and Windows Server.
- On Windows PowerShell 5.0/5.1,
$PSVersionTable.PSEditionis set toDesktop.
PowerShell Core is the edition of PowerShell built on top of .NET Core
(sometimes simplified to “CoreCLR”, though it technically includes CoreFX as well).
- PowerShell Core is cross-platform, available on Windows, macOS, and Linux, thanks to the cross-platform nature of .NET Core.
- On PowerShell Core,
$PSVersionTable.PSEditionis set toCore.
Note: while PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Nano Server.
Compatibility
Our goal with PowerShell Core is to remain as compatible with Windows PowerShell as technically possible. To that end, we’re leveraging a technology called .NET Standard 2.0 to provide binary compatibility with existing .NET assemblies. Many PowerShell modules depend on these assemblies (often times DLLs), so .NET Standard allows them to continue working with .NET Core. You can learn more about .NET Standard on the .NET Blog, YouTube, and via this excellent FAQ on GitHub.
We’ve also done our best to make sure that all aspects of the PowerShell language and “built-in” modules (e.g. Microsoft.PowerShell.Management, Microsoft.PowerShell.Utility, etc.) work the same as they do in Windows PowerShell. In many cases, with the help of our amazing community, we’ve added new capabilities and bug fixes to those cmdlets.
Most of the modules that ship as part of Windows (e.g. DnsClient, Hyper-V, NetTCPIP, Storage, etc.) have not been explicitly ported to .NET Core yet. However, with the promise of .NET Standard and CDXML, many of these traditional Windows PowerShell modules work great in PowerShell Core.
To that end, we ask that you give the latest PowerShell Core beta a try on Windows with your existing modules and scripts, and tell us what does and doesn’t work for you on GitHub. That includes modules available from the PowerShell Gallery. If you’ve tried it in PowerShell Core 6.0, we want to know about it!
When you’re ready to install and give it a try, just hop on over to our README’s install instructions and pick the instructions for your platform of choice. PowerShell Core is completely side-by-side with your existing Windows PowerShell installation, so you don’t have to worry about breaking any of your existing scripts or workloads. Plus, PowerShell Core doesn’t require any reboots at install-time, so you can start using it immediately!
You should also expect a more advanced, developer-oriented blog post from us in the near future about how to:
- port existing Windows PowerShell modules to PowerShell Core
- develop new modules that target both Windows PowerShell (downlevel to 3.0) and PowerShell Core
Future of Windows PowerShell
Windows PowerShell 5.1, much like .NET Framework 4.x, will continue to be a built-in, supported component of Windows 10 and Windows Server 2016. However, it will likely not receive major feature updates or lower-priority bug fixes. With PowerShell Core, we are actively addressing bugs that may have existed in previous versions of Windows PowerShell. We’re even open to contributions so that these bug fixes can be made by members of our community.
There are no changes to the support cycles for the shipping version of Windows Management Framework (WMF).
Timeline
Our current timeline is highly dependent on the level of verifiable compatibility between first-/third-party Windows PowerShell modules and PowerShell Core. In other words, by verifying your existing scripts/cmdlets work on PowerShell Core 6.0 (and telling us about it!), the sooner we’ll feel confident in getting to production.
That being said, it is our strong desire to ship a high-quality PowerShell Core 6.0 by the end of the year that you can feel confident about deploying in production. When this happens, we also plan on having more details about how you can use PowerShell Core 6.0 with official support from Microsoft.
Stay tuned!
Joey Aiello
Program Manager, PowerShell