The goals of PowerShell Core 6

There have been three primary goals for PowerShell Core 6:

When we examine each of these goals, it becomes clear how PowerShell Core came into being and why it is a great management tool for any infrastructure:

• Ubiquity describes the platform-independency to work with PowerShell on Windows, Linux, and macOS operating systems. This is necessary because heterogenous environments are today's norm, and they are important to developers and IT professionals.
• Cloud refers to the intention of being built for cloud scenarios, because IT is moving towards Azure, REST APIs (Swagger/OpenAPI), and other public clouds. For this, major improvements have been made to the Invoke-WebRequest, Invoke-RestMethod, and ConvertFrom-Json cmdlets. There is a collaboration with the Azure PowerShell team to support PowerShell Core. Third-party vendors, such as VMware and AWS, are also working to support PowerShell Core.
• Community refers to being open source, contributing directly to the product, and allowing the retrieval of customer feedback directly to the engineering team. The current Request for Comments (RFCs)—asking for feedback for the current roadmap/new features or breaking changes, milestones, projects, and issues—should always be transparent and publicly available. This means that we have pull requests against code, tests, and documentation. In addition, issues from the community are dynamically reprioritized, which can also be discussed in the PowerShell Core Community Call. These calls are free to join for everybody, and you can just raise your voice and discuss your feedback directly with the engineers.

Dependencies and support

As you know, PowerShell Core 6 and all following PowerShell versions depend on .NET Core. The first version of .NET Core was released in 2016:

On August 14, 2017, .NET Core 2 was released, on which PowerShell Core 6.0 is based. It implements .NET Standard 2.0 with the following conditions (https://github.com/dotnet/standard):

• .NET Standard defines a set of APIs that have to be implemented by all .NET platforms, as shown in the following diagram
• .NET Standard 2.0 is implemented by .NET Core
• .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries
• .NET Standard will replace Portable Class Libraries (PCLs)

You can see the .NET Standard API definition in the .NET/standard repository on GitHub.

In the following diagram, you can see this implementation for all .NET platforms:

Though there were no substantial changes made to the language itself in the .NET Standard 2.0 Release, the increase in API size—and hence, the tools available—more than justified the increased footprint:

Version	Number of APIs	Growth %
1.0	7,949
1.1	10,239	+29%
1.6	13,501	+32%
2.0	32,638	+142%

.NET Standard 2.0 includes the most important APIs and brings almost all .NET Framework 4.6.1 APIs to .NET Core 2.0:

PowerShell Core will be supported by Microsoft's Modern Lifecycle Policy.

The Modern Lifecycle Policy covers products and services that are serviced and supported continuously. Under this policy, the product or service remains in support if the following criteria are met:

• Customers must stay current as per the servicing and system requirements published for the product or service
• Customers must be licensed to use the product or service
• Microsoft must currently offer support for the product or service

Compatibility

Because of the changed underlying .NET Framework, compatibility may also have changed. One big benefit here is that .NET Standard 2.0 is implemented with .NET Core, which provides a binary compatibility with existing .NET assemblies. Because many PowerShell cmdlets and modules depend on them, these continue to work with .NET Core.

Many modules shipped as part of Windows haven't been explicitly ported to .NET Core, but may also continue working with the underlying .NET Standard and the implementations of CDXML. The CDXML files define the mappings between PowerShell cmdlets, and CIM class operations, or methods. Everything that is implemented with a CDXML should keep working.

But there are also some known exceptions:

• Workflows
• Snap-ins
• DSC resources (for now, moves to DSC Core)
• WMI v1 cmdlets (Get-WmiObject, Invoke-WmiMethod, and so on)
• A handful of other missing cmdlets

After the first public release of PowerShell Core, we are currently seeing the community and the product groups port their modules and cmdlets to PowerShell Core. It will take some time before most of the existing cmdlets continue to work on PowerShell Core.

Due to some naming collisions in Linux environments, the executable of PowerShell Core has been renamed from PowerShell.exe to pwsh.exe.

Cross-platform remoting

With the focus of being platform-independent, some changes to the remoting techniques had to be made. As you can see in the following diagram, PowerShell Core supports PowerShell Remoting (PSRP) over WSMan with Basic authentication on macOS and Linux, and with NTLM-based authentication on Linux. Kerberos-based authentication is not yet supported.

PowerShell Core also supports PSRP over SSH on all platforms (Windows, macOS, and Linux). Since this feature is still actively being developed, it is not recommended to use it in production. We will look at how to establish remote connections in Chapter 3, Basic Coding Techniques, and Chapter 4, Advanced Coding Techniques:

OpenSSH can be installed on Windows 10 1709 and later via the optional features: