SOLVED
Home

Predominance of PowerShell Core 6.0

Highlighted
Kurt Mackie
Occasional Contributor

Predominance of PowerShell Core 6.0

Do existing PowerShell scripts need to be rewritten in PowerShell Core 6.0? Could things break if that's not done? When might scripts need to be rewritten - that is, what's the overall timeline for the switch to PowerShell Core?

11 Replies

RE: Predominance of PowerShell Core 6.0

I was wondering the same thing

RE: Predominance of PowerShell Core 6.0

I suppose that really depends on what the script is doing and if the cmdlets used exist in Core. A script using Get-Date will still work fine but then a script with Get-WmiObject will not.

RE: Predominance of PowerShell Core 6.0

The answer to that is - it depends. Based on what cmdlets you are using, modules, snap-ins, you will most likely be faced with rewriting some of your code. Consuming Web Services should be an easy transition, while traditional Windows automation (AD, Exchange, etc.) and 3rd party snap-ins will pose a problem.

RE: Predominance of PowerShell Core 6.0

In my experience so far, any script of above minimal complexity will likely need some changes.
Solution

RE: Predominance of PowerShell Core 6.0

Existing Windows PowerShell scripts will continue to work on Windows PowerShell as it's fully supported so there's no requirement to port existing scripts to PSCore6. Since PSCore6 works side-by-side with Windows PowerShell, you should be able to use both concurrently. If you want to leverage some of the new language or cmdlets enhancements with PSCore6, you may have to make some changes to existing scripts if they have dependencies on Windows PowerShell specific modules. Over time as we get more cmdlet coverage on PSCore6, this will be less of an issue. There is currently no plan to remove Windows PowerShell nor put PSCore6 inbox on Windows.

Re: Predominance of PowerShell Core 6.0

Many Windows PowerShell scripts will (and do) work just fine on PowerShell Core. Ultimately, your compatibility is going to depend on whether or not the underlying .NET or cmdlet dependencies are available in PowerShell Core. Many of the .NET classes that you might use with Add-Type or as a required assembly in your module are available as part of .NET Standard. Many modules already support PowerShell Core (as you can see on the Gallery), and even some that don't explicitly support PowerShell Core "just work" when you add your Windows PowerS....

 

Over time, we'll be doing more to make modules more compatible via the WindowsPowerShellCompatibilityPack module. 

 

As for the "switch to PowerShell Core", we hope that you're able to switch as soon as possible, but due to the amount of usage, we'll be supporting Windows PowerShell for a long time. At least as long as Windows 10 and Windows Server 2016 are supported, as Windows PowerShell is a shipping component in those: https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet 

Re: RE: Predominance of PowerShell Core 6.0

Steve's response might have been marked as the "best response",  but it's incomplete. There are significant breaking changes between PS 5.1 and PS 6.0. The release documentation goes into some of them in detail (but the only relatively complete list is to look at the changelog on GitHub). Some of these changes will fail silently.

 

You literally will need to re-test non-trivial scripts to ensure they still work the same way on PS 6 as they did previously.

RE: Predominance of PowerShell Core 6.0

Most of the automation stuff I am responsible for will just stay where it is. Reliance on modules that provide valuable resources (AD, PowerCLI, Hyper-V) either do not work or will take some form of hoop jumping which will then render them unreadable for the general audience.

Re: RE: Predominance of PowerShell Core 6.0

If you're making the conscious decision to switch to PowerShell Core, wouldn't you always test scripts?

Re: RE: Predominance of PowerShell Core 6.0

I would certainly hope so. But that's not the vibe I'm getting from the PS team.

Re: RE: Predominance of PowerShell Core 6.0

Michael is correct that although many scripts may work, we did make some small changes based on community feedback that may change behavior is more subtle ways.  One should always test their scripts before deploying them.  There is work happening to create PSScriptAnalyzer rules to identify parts of script that are not PSCore6 compatible.