With the change to CoreCLR 2.0 which conforms with .Net Std 2.0 as well as the update to enable searching the GAC for assemblies, we need validation that PSCore6 is a viable replacement for Windows PowerShell 5.x. Please list modules you've tried that do not work here. Vote with 馃憤 for which modules you most care about to help us prioritize how we work with partners to enable support or have them port to target .Net Std 2.0.
Until https://github.com/PowerShell/PowerShell/issues/4056 gets resolved, you'll need to manually add Windows PowerShell PSModulePath to discover those modules:
PS > $env:psmodulepath += ";${env:userprofile}\Documents\WindowsPowerShell\Modules;${env:programfiles}\WindowsPowerShell\Modules;${env:windir}\system32\WindowsPowerShell\v1.0\Modules\"
PSSnapins:
Failing due to Add-Type
Basic tests work:
Needs to be ported:
Not sure:
Workflow is not something we're planning on supporting. Instead we're committed to improving the concurrency/parallel execution experience in PowerShell script which we believe is the primary reason people used Workflows. If there's other reasons, let me know.
ConvertFrom-String relies on technology from Microsoft Research that currently isn't planned to be Open Source.
I appreciate the feedback, though.
Workflow and ConvertFrom-String are independent with different reasons why they are not in plan to be in PSCore6. I would agree that ConvertFrom-String would work great against existing text based native utils on Linux. Perhaps we can create a new cmdlet with similar, but simpler capability as ConvertFrom-String.
ConvertFrom-string, or similar functionality, would be extremely useful
I checked the Windows PowerShell module load on Windows 10 ver 16215 with RSAT installed.
Script and results (including errors) in attached file.
4062a.txt
4062b.txt - full list modules from PowerShell Core.
In short.
Total Core modules = 12.
Total Windows and Core modules = 120.
Total Windows modules = 108. ( In Windows Powershell Get-Module -ListAvailable).count = 109 )
After PowerShell Core start - 3 modules is loaded.
After attempting to load all modules - 71 modules is loaded.
So 59 from 108 Windows modules is loaded.
$error.count = 79
@iSazonov thanks for getting those results.
cc @PowerShell/powershell-committee
Oh, ActiveDirectory module is PSSnapIn 馃槙 The main consumers of PowerShell Core (system administrators) are thrown overboard!
We'll have to talk to that team about rewriting their cmdlet...
Exchange Server 2013 EMS crushed PowerShell Core. Also it can not find Exchange assemblies.
SCCM 2012 R2 module is not loaded - broken .Net dependences and not found assemblies in local (SCCM home) folder.
Sharepoint 2013 module is PSSnapIn.
On MacOS and Linux:
Install-Module Docker -Scope CurrentUser -Repository DockerPS-Dev
Get-Container
Could not load file or assembly 'Docker.DotNet, Version=2.124.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
At line:1 char:1
So do I correctly infer from comments above that ActiveDirectory isn't working because it's a PSSnapIn, not a Module, and this version doesn't support snapins?
Also, while I could Import-Module -Name MSOnline, when I tried Connect-MsolService, I got a "Could not load type 'System.Drawing.Drawing2D.InterpolationMode' from assembly 'System.Drawing', then powershell.exe crashed.
@JakeMoe Yes, PSSnapIn is deprecated in PowerShell Core.
System.Drawing
is not in CoreFS and .Net Standard 2.0.
@iSazonov could you try those three (Exchange, SharePoint, and SCCM) again with beta.4? Thanks!
And thanks to everyone else, keep 'em coming!
PS C:\Program Files\PowerShell\6.0.0-beta.4> Import-Module MSOnline
Import-Module : Could not load type 'System.Diagnostics.EventLogEntryType' from assembly 'System, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089'.
PS > Start-Process powershell -Credential (Get-Credential)
Windows PowerShell credential request
Enter your credentials.
User: domain\username
Password for user domain\username: **************
Start-Process : Unable to load DLL 'api-ms-win-security-cpwl-l1-1-0.dll': The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ Start-Process powershell -Credential (Get-Credential)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Start-Process], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.StartProcessCommand
@joeyaiello
at System.Management.MTAHelper.IsNoContextMTA()
at System.Management.MTAHelper.CreateInMTA(Type type)
...
I again checked the Windows PowerShell module load on Windows 10 ver 162241 with RSAT installed.
Script and results (including errors) in attached file.
4062Beta4fulllist.txt
4062Beta4ipmoall.txt - full list modules from PowerShell Core.
In short.
Total Core modules = 12.
Total Windows and Core modules = 125.
Total Windows modules = 113.
After PowerShell Core start - 2 modules is loaded.
After attempting to load all modules - 108 modules is loaded.
So 96 from 113 Windows modules is loaded.
$error.count = 47
checked one of my custom scripts with Beta 4 but it aborts with error:
catch:function: Process: Error:Exception calling ".ctor" with "0" argument(s): "Could not load type 'System.Diagnostics.PerformanceCounter' from assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'."
opened #4295
Edited by @daxian-dbw:
The root cause is that System.Diagnostics.PerformanceCounter
is currently not available in .NET Core
. dotnet/corefx#3906 is tracking the PerformanceCounter
support in .NET Core
but it's marked with the 'Future' milestone which means it won't be available in .NET Core 2.0
.
Please see #4295 for more information.
@mi-hol Please open new Issue-Question.
Can't get Get-WUList to work in 6.0 core beta-4 from PSWindowsUpdate version 1.6.0.3. It works fine on Windows 10 Desktop PowerShell.
Output:
Get-WUList -MicrosoftUpdate
Test-Connection : The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests. Consult the logs and
documentation for the WS-Management service running on the destination, most commonly IIS or
WinRM. If the destination is the WinRM service, run the following command on the destination to
analyze and configure the WinRM service: "winrm quickconfig".
At C:\Program Files\WindowsPowerShell\Modules\PSWindowsUpdate\1.6.0.3\Get-WUList.ps1:274 char:7
+ If(Test-Connection -ComputerName $Computer -Quiet)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Test-Connection], CimException
+ FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnection
Command
$PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-beta
PSEdition Core
GitCommitId v6.0.0-beta.4
OS Microsoft Windows 10.0.15063
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
@fdncred Thanks for your report!
I tested PSWindowsUpdate.
Both WebAdministration and IISAdministration do not run in PS Core because they expect GAC'd assemblies to be available. Using DSC is likely a better alternative but applying configuration in core is awkward due to the lack of Invoke-DSCResource
and Start-DSCConfiguration
. see #4457.
Any update on issue, Cant't import MsOnline module on Linux based OS. #4269
Invoke-MySqlQuery from the PowerShell Gallery doesn't work. I get an error when I try to use it on Beta 5 on Windows 10. My understanding of the .Net Standard was that there is a chance that this should work on Windows (not on Linux/Mac of course). The assembly does get loaded, just get's an error on one of the most common method in it.
https://www.powershellgallery.com/packages/Invoke-MySqlQuery/1.0.0/DisplayScript
Install-Script -Name Invoke-MySqlQuery
. Invoke-MySqlQuery.ps1
$MyCred = Get-Credential
Invoke-MySQLQuery -ComputerName MyServer -Database mysql -Query "select @@hostname" -Credential $MyCred
Exception calling "Open" with "0" argument(s): "The type initializer for 'MySql.Data.MySqlClient.Replication.ReplicationManager' threw an exception."
I also have an internal module that has the same issue on Conn.Open(). We use the internal module to connect to 100s of MySql servers and to AWS Aurora as well.
This happens with both Connector/Net 6.9.9 and Connector/Net 8.0.8 (installed on different computers). It works in previous versions of PowerShell without any issues.
@FireInWinter Thanks for your report! Please open new Issue with steps to reproduce the problem.
We need to be able present forms. Ideally, via System.Drawing, but if need be, I could convert some to XAML. However, neither work, so is anything graphical with Powershell dead? We'll never cut over to PowershellCore if we can't use some sort of form. And no, we're not going to use C# :P
Also, is it safe to say Get-WmiObject is dead? I wish the syntax between Get-WmiObject and Get-CimInstance was identical, but they aren't, so you are forced to code twice if you still have any PS 2.0 out there.
@agressiv we have some investigations going on for https://github.com/PowerShell/PowerShell/issues/3957 to enable GUIs
Get-WmiObject
is considered deprecated. @joeyaiello just posted a blog about us formally deprecating PSv2. We have been recommending for some time to switch to the CIM cmdlets instead of using the WMI cmdlets which can interop with non-Windows implementations of CIM over WSMan (OpenPegasus, OMI, Dell iDrac, HP iLO, etc...).
We still have machines on 2.0 because Microsoft was slow in supporting WMF 4.0 on many core products, and our migration is over. We'll have to make another pass to see who is left since we are now being asked to deploy 5.1 (which of course, isn't compatible with just about everything including Skype and Exchange Servers)
Is there a list of Cmdlets like Get-WmiObject which will be removed that we can refer to?
What is the target platform for WinPE? Will it move to core as well? We use Windows Forms there as well.
I did a dump of all cmdlets in the 6.0 beta and simply did a compare-object. here's the ones for us:
@agressiv VMware PowerCLI is now a module that can be installed from the PowerShell Gallery, and I'm almost certain they're supporting PowerShell Core with it already (I'd need to double-check that though). There are other PSSnapin stragglers out there though, as you point out.
@agressiv for PSCore6, we deliberately removed support for PSSnapins. However, VMWare has a port of PowerCLI for PSCore6 that is not currently on PSGallery
@aggresiv: On the UI front, we're definitely not abandoning GUI efforts altogether, we're just not sure exactly where we're headed yet. If you pop on over to https://github.com/PowerShell/Phosphor, you can check out an experiment we're running to try and generate web-based UIs (which avoid a lot of the problems around disparate "native" UI frameworks, though if someone wants to make some Qt bindings for PowerShell, that'd also make me very happy).
As for Get-WmiObject
: you're right, we don't have any plans to bring it back. In my opinion, Get-CimInstance
immensely improved on the syntax as Get-WmiObject
(part of the reason it was made in the first place), and while I understand the pain of double-coding, we also just deprecated Windows PowerShell 2.0, so we're not going to be optimizing for back compat to 2.0 going forward. :\
My use cases:
If you can make all of those and their cmdlets work under Windows, Linux and MacOS, you will be heralded as heroes.
I imagine the AD module being the toughest, as it is currently part of RSAT and a snap-in, as explained in earlier comments. But hey, the AD team's gotta get on with the times!
If all else fails, then remote PowerShell session to a domain controller or another Windows computer that has these modules and then import the session.
@KeeperB5 implicit remoting by importing a PSSession should just work with PSCore6 (Windows anyways, haven't tried with Linux/MacOS, but should work)
Import-Module AzureAD
Connect-AzureAD
Unhandled Exception: System.TypeLoadException: Could not load type 'System.Drawing.Icon' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at System.Windows.Forms.Form.Dispose(Boolean disposing)
at System.ComponentModel.Component.Finalize()
connect-azuread : One or more errors occurred. (Could not load type 'System.Drawing.Drawing2D.InterpolationMode' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.): Could not load type 'S
ystem.Drawing.Drawing2D.InterpolationMode' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
At line:1 char:1
connect-azuread
CategoryInfo : AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException
FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD
Also, the whole application crashes with the message "powershell.exe has stopped working"
Moving this out of 6.0.0 milestone as there's no planned additional work for 6.0.0
@SteveL-MSFT Could you clarify if it possible - what is MSFT plan/timeline to adopt modules of their products for PowerShell Core 6.0?
Many product teams won鈥檛 start any validation work until we get to a 6.0.0 final release, so focus is to get that done and engage with the product teams to start validation. This won鈥檛 happen quickly unfortunately so there鈥檚 no timeline I can provide at this time.
Based on this issue, is there a plan to port the Active Directory/Exchange modules to PowerShell v6? Will the tools be Windows only (since System.DirectoryServices.Protocols currently runs only on windows)?
@j3vans CoreFX has still very limited API and I don't expect that MSFT teams can port these modules. We can use Windows modules via remoting.
Install-Module SqlServer doesn't install on Mac.
```Steps to Reproduce:
Install-Module SqlServer
Errors out with:
PackageManagement\Install-Package : Unable to load DLL 'api-ms-win-core-sysinfo-l1-1-0.dll': The specified module or one of its dependencies could not be found. (Exception from HRESULT: 0x8007007E) At /usr/local/microsoft/powershell/6.0.0-rc.2/Modules/PowerShellGet/1.6.0/PSModule.psm1:2057 char:21 + ... $null = PackageManagement\Install-Package @PSBoundParameters + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.TestModuleManifestCommand,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
```powershell
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-rc.2
PSEdition Core
GitCommitId v6.0.0-rc.2
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct 4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
About "Install-Module SQLServer" - This module is meant for Windows system only. There are no Linux/Mac SQLPS nor SQLServer modules (yet).
Now, if you want try building your own SQL Server PowerShell commands on non-Windows systems, You can install the "Microsoft.SqlServer.SqlManagementObjects" which will run in Linux.
See my blog post for more information: http://www.maxtblog.com/2017/11/streamlining-sql-server-management-objects-smo-in-powershell-core/
this issue will be addressed by https://github.com/PowerShell/WindowsPowerShellCompatibilityPack please open issues for specific modules there
Is there any work in progress to have a functional Active Directory module for PS 6?
Hi @apetitjean,
You may want to post the question at @SteveL-MSFT link above. This way it can be tracked properly.
:)
See you at the MVP Summit!
Thank you @MaximoTrinidad. Posting here was exactly my intention. I hope @SteveL-MSFT will see my question here.
Indeed see you soon! :)
@apetitjean the plan is to be able to support Active Directory module via the Windows PowerShell Compatibility Pack. Most likely we'll use implicit remoting and perhaps with JEA.
@SteveL-MSFT Windows PowerShell Compatibility Pack will be windows only, correct? I don't think it is acceptable for an Active Directory module to work only on Windows. If the plan is to temporarily support support AD only on Windows until the required .NET Core APIs are made x-plat, than I'm ok with that. But, AD is used for more than just Windows environments and the ability to build automation in Linux (and macOS) using PowerShell should not require direct .NET manipulation or calling out to other shell/scripting languages which can support AD on Linux.
From my understanding the Active Directory module is not in the PowerShell
Team's plate and it should be completely rewritten to work with PowerShell
Core.
I think what Steve is talking about is a workaround that should work until
the next AD module release.
The current AD module has PSSnapin requirements which wont work in PS Core anyway, unless we are adding some PSSnapin shim in the Windows PowerShell Compatibility Pack I am not aware of... the only way for an AD module would be a re-write. This is why I'm disturbed @SteveL-MSFT saying AD module (even though it is the OS team's responsibility, and not the PowerShell Team) would be supported by Windows PowerShell Compatibility Pack. There was already a critical need for refactoring the module for core, and if its future is in the Windows PowerShell Compatibility Pack, then that is the wrong direction.
I'm with @markekraus opinion. I really not in favor of using Windows PowerShell Compatibility Pack and I think "... it should keep them separated!!".
But that's my take!
:)
My understanding of Windows PowerShell Compatibility Pack was that it contains all that never will be ported.
The intent of the Windows PowerShell Compatibility Pack is to temporarily help existing Windows PowerShell users move to PSCore6. The long term plan is to have modules natively run on PSCore6 as well as be cross platform. Some teams may decide they will never port to PSCore6 or they will, but not invest in making it cross platform compatible. The biggest influencer to help them make the _right_ decision is customer feedback (not the PowerShell Team where we represent the customer).
Understood. and for anyone who feels the way I do:
and
If I have scripts that have dependencies on .Net framework dlls, I should look for a .Net core version of those dependencies via nuget and then try to port the script to PS6? There is no "wrapper" for these dependencies, correct?
@dudeNumber4 it depends. If it's an assembly PSCore6 already includes (and we include a lot), then you shouldn't need to make any change unless you refer to a specific dll via path. For example, if you were dependent on System.DirectoryServices.AccountManagement.dll previously using Add-Type to load, if you didn't specify a path, it should just work.
@dudeNumber4 it depends. If it's an assembly PSCore6 already includes (and we include a lot), then you shouldn't need to make any change unless you refer to a specific dll via path. For example, if you were dependent on System.DirectoryServices.AccountManagement.dll previously using Add-Type to load, if you didn't specify a path, it should just work.
OK, just attempted New-Object System.Data.OleDb.OleDbConnection
. _Cannot find type_. On nuget, I see some kind of port that claims support for .Net Standard 2.0. To port the script I'd have to add a nuget restore of that library, correct?
@dudeNumber4 we don't include that assembly as part of PSCore6 itself, so to use it, you should be able to use Install-Package
to download that nupkg at runtime, or do it manually and just include that assembly with your script.
WebAdministration - is xWebAdministration the replacement, or will WebAdministration be ported?
@IanKemp that module is owned by the IIS team so I don't know their plans. However, last time my team looked at that module some of the necessary .Net Framework namespaces were not available in .Net Core, so until that happens it wouldn't work unless they rewrite it
Most helpful comment
We'll have to talk to that team about rewriting their cmdlet...