{"id":17970,"date":"2019-08-20T15:02:43","date_gmt":"2019-08-20T23:02:43","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/powershell\/?p=17970"},"modified":"2019-11-18T19:02:44","modified_gmt":"2019-11-19T03:02:44","slug":"powershell-7-preview-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershell-7-preview-3\/","title":{"rendered":"PowerShell 7 Preview 3"},"content":{"rendered":"
\n

<\/a>PowerShell 7 Preview 3<\/h2>\n

In May, we published our PowerShell 7 Roadmap<\/a>. We have been making progress on our roadmap and are currently on track to have a Generally Available (GA) release by end of this calendar year.<\/p>\n

<\/a>Long Term Servicing<\/h2>\n

PowerShell 7 GA will also be our first Long Term Servicing (LTS) release which is a change from our current Modern Lifecycle support <\/a>for PowerShell Core 6.\nWe will support PowerShell 7 GA for as long as .NET Core 3.1 is supported<\/a> before you must upgrade to a newer version to continue to be supported by Microsoft.<\/p>\n

<\/a>Windows PowerShell compatibility<\/h2>\n

One of the main goals of PowerShell 7 is to have a viable replacement for Windows PowerShell 5.1 in production and we’ve made significant progress towards that goal.<\/p>\n

PowerShell 7 Preview 3 is built on .NET Core 3.0 Preview 8<\/a> and leverages the work from the .NET Team <\/a>to close the gap between .NET Core and .NET Framework. .NET Core 3.0 reintroduces a large number of .NET Framework APIs, opening up a large number of PowerShell modules shipped with Windows to be validated and marked as compatible by our team. Because the compatibility changes to the modules come as part of Windows, the latest version of Windows 10\/Windows Server is required for full module compatibility.<\/p>\n

However, on older versions of Windows, some modules may just work if you use:<\/p>\n

\n
Import-Module <moduleName> -SkipEditionCheck<\/pre>\n<\/div>\n
If you have issues with a Microsoft PowerShell module, please open an issue in the PowerShellModuleCoverage<\/a> repository!<\/p>\n
Expect more content on this specific topic from Joey Aiello<\/a> in the near future with more detail on which modules are compatible and where they’re marked as such.<\/p>\n
<\/a>New Features in Preview 3<\/h2>\n
This is just a small part of the entire changelog<\/a>.\nNew features in this preview from the community and also the PowerShell team:<\/p>\n
<\/a>Experimental Features on by default in Preview builds<\/h3>\n
We decided to enable all Experimental Features <\/a>by default in order to solicit more feedback for the PowerShell Committee<\/a> to determine if a feature should continue as experimental, move from experimental to stable (non-experimental), or be withdrawn. On Stable builds (as well as Release Candidates), experimental features will continue to be disabled by default.<\/p>\n
Note that if you had previously manually enabled experimental features<\/a>, your powershell.config.json<\/code>settings file will take precedence and only experimental features listed within that file will be enabled. You can delete that file or run Get-ExperimentalFeature | Enable-ExperimentalFeature<\/code> to ensure all experimental features are enabled. However, if you use the pipeline, you’ll have to do it again with a future Preview release that has new experimental features.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Single Apartment Thread as default<\/h3>\n
In general, you don’t need to worry about a concept called ApartmentState<\/a> which only applies to Windows.<\/p>\n
Prior to this release pwsh<\/code> would run as a multi-threaded apartment by default. However, graphical user interface (GUI) APIs such as WinForms<\/a> and WPF<\/a> require a single-threaded apartment. What is important here is that pwsh<\/code> is now the same as powershell.exe<\/code> in regards to apartment state and as such support calling WinForms and WPF APIs from PowerShell script.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Display COM Method Signature Argument Names<\/h3>\n
On Windows, if you happen to call COM APIs from PowerShell, a new capability by nbkalex<\/a> will now show the argument names of COM methods instead of just the type information which can be used as simple documentation indicating what arguments should be passed.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Consider DBNull and NullString as $null<\/h3>\n
If you work with database types, you may get back a [dbnull]::Value<\/code> which is equivalent to $null<\/code> within the database, but in PowerShell, this was not equal to $null<\/code> so you can’t compare it directly. This change from Joel Sallow<\/a> allows you to compare both [dbnull]::Value<\/code> and [nullstring]::Value<\/code> to $null<\/code> and get $true<\/code>.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Read-Host -Prompt works for all input<\/h3>\n
Due to how Read-Host<\/code> calls into the console host and how the console host prompts for input (such as mandatory parameters that are given a value), you might encounter a situation where using Read-Host<\/code> to prompt for input in your script exhibits unintended behavior when certain characters are used. This has been fixed so Read-Host<\/code> will accept input as expected.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Support negative numbers with -Split operator<\/h3>\n
The -Split operator<\/a> splits one or more strings into substrings. You can optionally specify a value to indicate the maximum number of substrings you want returned.<\/p>\n
This new capability by Jacob Scott<\/a> now allows you to specify the maximum number of substrings as a negative value signifying that the split should happen right to left instead of the usual left to right.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>ForEach-Object -Parallel<\/h3>\n
We’ve received consistent feedback that PowerShell users use PSWorkflow<\/a> primarily to easily run scriptblocks in parallel.<\/p>\n
We’ve added a -Parallel<\/code> parameter to ForEach-Object<\/code><\/a> that accepts a scriptblock to execute in parallel. There is an optional -ThrottleLimit<\/code> parameter to set the maximum threads to use in parallel where it defaults to 5.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>Resolve AppX reparse points<\/h3>\n
On Windows 10, if you have apps installed from the Windows Store<\/a> and list them in the command line, they show up as 0 byte files. These files are actually a different type of link to the actual executable. With this change, the target executable will now show up when using Get-ChildItem<\/code><\/a>.<\/p>\n
\"gif\"<\/a><\/p>\n
<\/a>pwsh as a login shell<\/h3>\n
On Linux and macOS systems, there is a concept of a login shell which sets up the environment from which other apps and shells inherit. Prior to this release if you used pwsh<\/code><\/a> as your default login shell, you may have noticed that some environment variables are missing or incomplete.<\/p>\n
With this change, pwsh<\/code> will work the same as sh<\/code> Bourne Shell<\/a> in how it sets up the login environment so that everything works correctly.<\/p>\n
<\/a>Additional Telemetry<\/h3>\n
In this Preview release, we’ve added more telemetry<\/a>. Please see Sydney Smith<\/a>‘s blog post on New Telemetry in PowerShell 7 Preview 3<\/a>.<\/p>\n
<\/a>Closing<\/h2>\n
Although this blog post focuses on new features, this release also contains many bug fixes as well as targeted performance improvements.<\/p>\n
You can always get the latest version of PowerShell from https:\/\/aka.ms\/get-powershell<\/a>.<\/p>\n
Expect more new features from the community and the PowerShell team in future Preview releases!<\/p>\n
Steve Lee\nPowerShell Team<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
PowerShell 7 Preview 3 In May, we published our PowerShell 7 Roadmap. We have been making progress on our roadmap and are currently on track to have a Generally Available (GA) release by end of this calendar year. Long Term Servicing PowerShell 7 GA will also be our first Long Term Servicing (LTS) release which […]<\/p>\n","protected":false},"author":685,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-17970","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"blog_post_summary":"
PowerShell 7 Preview 3 In May, we published our PowerShell 7 Roadmap. We have been making progress on our roadmap and are currently on track to have a Generally Available (GA) release by end of this calendar year. Long Term Servicing PowerShell 7 GA will also be our first Long Term Servicing (LTS) release which […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/17970","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/685"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=17970"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/17970\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=17970"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=17970"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=17970"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}