Powershell: Módulos FullCLR não compatíveis com PSCore6

Fluxo de trabalho não é algo que planejamos oferecer suporte. Em vez disso, estamos comprometidos em melhorar a experiência de execução simultânea / paralela no script do PowerShell, que acreditamos ser o principal motivo pelo qual as pessoas usaram fluxos de trabalho. Se houver outros motivos, me avise.

ConvertFrom-String depende da tecnologia da Microsoft Research que atualmente não está planejada para ser Open Source.

Agradeço o feedback, no entanto.

Workflow e ConvertFrom-String são independentes por diferentes motivos pelos quais não planejam ser no PSCore6. Eu concordaria que ConvertFrom-String funcionaria muito bem com os utilitários nativos baseados em texto existentes no Linux. Talvez possamos criar um novo cmdlet com capacidade semelhante, mas mais simples, como ConvertFrom-String.

ConvertFrom-string, ou funcionalidade semelhante, seria extremamente útil

Eu verifiquei a carga do módulo do Windows PowerShell no Windows 10 ver 16215 com RSAT instalado.
Script e resultados (incluindo erros) no arquivo anexado.
4062a.txt
4062b.txt - lista completa de módulos do PowerShell Core.

Resumidamente.
Módulos do núcleo total = 12.
Total de módulos Windows e Core = 120.
Total de módulos do Windows = 108. (No Windows Powershell Get-Module -ListAvailable) .count = 109)
Após o PowerShell Core iniciar - 3 módulos são carregados.
Depois de tentar carregar todos os módulos - 71 módulos são carregados.

Portanto, 59 de 108 módulos do Windows são carregados.
$ error.count = 79

@iSazonov obrigado por obter esses resultados.

• As falhas de cmdlet com base em CDXML serão resolvidas assim que mudarmos para o núcleo dotnet mais recente que tem essa correção .
• A maioria dos erros se deve a aliases conflitantes para DSC.
• O módulo RemoteDesktop está chamando Add-Type, que falha e devemos investigar que
• Espera-se que o fluxo de trabalho um não funcione
• Espera-se que o ISE um não funcione
• ODataUtils é um da minha equipe que precisa ser portado cc @anmenaga

cc @ PowerShell / powershell-Committee

Ah, o módulo ActiveDirectory é PSSnapIn 😕 Os principais consumidores do PowerShell Core (administradores de sistema) são lançados ao mar!

Teremos que falar com essa equipe sobre como reescrever seu cmdlet ...

Exchange Server 2013 EMS esmagado PowerShell Core. Também não consegue encontrar assemblies do Exchange.

O módulo SCCM 2012 R2 não está carregado - dependências .Net quebradas e assemblies não encontrados na pasta local (inicial do SCCM).

O módulo do Sharepoint 2013 é PSSnapIn.

No MacOS e Linux:

Install-Module Docker -Scope CurrentUser -Repository DockerPS-Dev

Get-Container

Não foi possível carregar o arquivo ou assembly 'Docker.DotNet, Version = 2.124.0.0, Culture = neutral, PublicKeyToken = null'. O sistema não pode encontrar o arquivo especificado.
Na linha: 1 caractere: 1

• Get-Container
• ~ ~ ~~~
  
  
  
  • CategoryInfo: OperationStopped: (:) [], FileNotFoundException
  
  
  • FullyQualifiedErrorId: System.IO.FileNotFoundException
  
  

Portanto, deduzo corretamente dos comentários acima que o ActiveDirectory não está funcionando porque é um PSSnapIn, não um módulo, e esta versão não oferece suporte a snap-ins?

Além disso, embora eu pudesse Import-Module -Name MSOnline, quando tentei Connect-MsolService, recebi um "Não foi possível carregar o tipo 'System.Drawing.Drawing2D.InterpolationMode' do assembly 'System.Drawing', então o powershell.exe travou.

@JakeMoe Sim, PSSnapIn foi preterido no PowerShell Core.

System.Drawing não está em CoreFS e .Net Standard 2.0.

@iSazonov você poderia tentar esses três (Exchange, SharePoint e SCCM) novamente com beta.4? Obrigado!

E obrigado a todos os outros, continuem vindo!

PS C: \ Arquivos de programas \ PowerShell \ 6.0.0-beta.4> Import-Module MSOnline
Módulo de importação: Não foi possível carregar o tipo 'System.Diagnostics.EventLogEntryType' do 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

• Exchange - carregados, cmdlets simples funcionam
• Os cmdlets simples carregados por Sharepoint funcionam
• SCCM - NullReferenceException e travamento:

at System.Management.MTAHelper.IsNoContextMTA()
at System.Management.MTAHelper.CreateInMTA(Type type)
...

• Skype Server 2015 - Não foi possível carregar o tipo 'System.Management.Automation.PSSnapIn'.

Verifiquei novamente a carga do módulo do Windows PowerShell no Windows 10 versão 162241 com RSAT instalado.
Script e resultados (incluindo erros) no arquivo anexado.

4062Beta4fulllist.txt
4062Beta4ipmoall.txt - lista completa de módulos do PowerShell Core.

Resumidamente.
Módulos do núcleo total = 12.
Total de módulos Windows e Core = 125.
Módulos totais do Windows = 113.
Após o PowerShell Core iniciar - 2 módulos são carregados.
Depois de tentar carregar todos os módulos - 108 módulos são carregados.

Portanto, 96 de 113 módulos do Windows são carregados.
$ error.count = 47

verifiquei um dos meus scripts personalizados com Beta 4, mas aborta com erro:
catch: function : Process: Error: Exception chamando ".ctor" com "0" argumento (s): " Não foi possível carregar o tipo 'System.Diagnostics.PerformanceCounter ' from assembly 'System, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 '. "

abriu # 4295

Editado por @ daxian-dbw:
A causa raiz é que System.Diagnostics.PerformanceCounter não está disponível em .NET Core . dotnet / corefx # 3906 está rastreando o suporte PerformanceCounter em .NET Core mas está marcado com o marco 'Futuro', o que significa que não estará disponível em .NET Core 2.0 .
Consulte # 4295 para obter mais informações.

@ mi-hol Por favor, abra uma nova questão-questão.

Não é possível fazer o Get-WUList funcionar no 6.0 core beta-4 do PSWindowsUpdate versão 1.6.0.3 . Ele funciona bem no Windows 10 Desktop PowerShell.

Saída:

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 Obrigado pelo seu relatório!
Testei PSWindowsUpdate.

• Você tem um problema com Test-Connection e WS-Management. Não discuta isso no tópico - abra uma nova questão-questão se precisar de ajuda.
• Ainda não podemos usar PSWindowsUpdate porque # 3775.

WebAdministration e IISAdministration não são executados no PS Core porque eles esperam que os assemblies do GAC estejam disponíveis. Usar DSC é provavelmente uma alternativa melhor, mas aplicar a configuração no núcleo é estranho devido à falta de Invoke-DSCResource e Start-DSCConfiguration . consulte # 4457.

Qualquer atualização sobre o problema, não é possível importar o módulo MsOnline no sistema operacional baseado em Linux . # 4269

Invoke-MySqlQuery da Galeria do PowerShell não funciona. Recebo um erro quando tento usá-lo no Beta 5 no Windows 10. Meu entendimento do .Net Standard é que há uma chance de que funcione no Windows (não no Linux / Mac, é claro). O assembly é carregado, apenas obtém um erro em um dos métodos mais comuns nele.
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."

Eu também tenho um módulo interno que tem o mesmo problema no Conn.Open (). Usamos o módulo interno para nos conectar a centenas de servidores MySql e também ao AWS Aurora.

Isso acontece com o Connector / Net 6.9.9 e o Connector / Net 8.0.8 (instalados em computadores diferentes). Ele funciona em versões anteriores do PowerShell sem problemas.

@FireInWinter Obrigado pelo seu relatório! Abra um novo problema com as etapas para reproduzi-lo.

Precisamos ser capazes de apresentar formulários. Idealmente, via System.Drawing, mas se necessário, eu poderia converter alguns para XAML. No entanto, nenhum dos dois funciona, então há algo gráfico com o Powershell morto? Nunca passaremos para o PowershellCore se não pudermos usar algum tipo de formulário. E não, não vamos usar C #: P

Além disso, é seguro dizer que Get-WmiObject está morto? Gostaria que a sintaxe entre Get-WmiObject e Get-CimInstance fosse idêntica, mas não são, então você é forçado a codificar duas vezes se ainda tiver algum PS 2.0 disponível.

@agressiv , temos algumas investigações em andamento para https://github.com/PowerShell/PowerShell/issues/3957 para habilitar GUIs

Get-WmiObject é considerado obsoleto. @joeyaiello acaba de postar um blog sobre a suspensão formal do

Ainda temos máquinas no 2.0 porque a Microsoft demorou a dar suporte ao WMF 4.0 em muitos produtos principais e nossa migração acabou. Teremos que fazer outra passagem para ver quem sobrou, já que agora estamos sendo solicitados a implantar o 5.1 (que, claro, não é compatível com quase tudo, incluindo Skype e servidores Exchange)

Existe uma lista de cmdlets como Get-WmiObject que será removido para que possamos nos referir?

Qual é a plataforma de destino do WinPE? Ele também será transferido para o núcleo? Também usamos o Windows Forms.

Eu fiz um dump de todos os cmdlets no beta 6.0 e simplesmente fiz um compare-object. aqui estão aqueles para nós:

• Todos os cmdlets EventLog. Nós os usamos extensivamente.
• Test-ComputerSecureChannel.
• Add-PSSnapin. Adoraria não usar isso, mas aparentemente muitos módulos têm autores preguiçosos. (por exemplo, Vmware, WSUS, MDT, Citrix, SCOM, Dell). Talvez haja outras maneiras de carregar alguns desses módulos, mas esses OEMS são os que realmente usam Add-PSSnapin em seu código - então, ou estamos modificando seu código, esperando que funcione, ou eles finalmente o alteram. Claro, eles não deveriam ter usado Add-PSSnapin por uns 8 anos agora, mas algumas coisas nunca mudam.

@agressiv VMware PowerCLI agora é um módulo que pode ser instalado a partir da Galeria do PowerShell, e tenho quase certeza de que eles já oferecem suporte ao PowerShell Core (no entanto, preciso verificar isso novamente). Existem outros retardatários do PSSnapin por aí, como você indicou.

@agressiv para PSCore6, removemos deliberadamente o suporte para PSSnapins. No entanto, VMWare tem uma porta de PowerCLI para PSCore6 que não está atualmente no PSGallery

@aggresiv : No front da interface do usuário, definitivamente não estamos abandonando os esforços da GUI completamente, apenas não temos certeza de para onde estamos indo ainda. Se você acessar https://github.com/PowerShell/Phosphor , poderá verificar um experimento que estamos executando para tentar gerar interfaces de usuário baseadas na web (o que evita muitos dos problemas em torno de diferentes interfaces de usuário "nativas" frameworks, embora se alguém quiser fazer algumas ligações Qt para PowerShell, isso também me deixaria muito feliz).

Quanto a Get-WmiObject : você está certo, não temos planos de trazê-lo de volta. Na minha opinião, Get-CimInstance melhorou imensamente na sintaxe como Get-WmiObject (parte da razão pela qual foi feito em primeiro lugar), e embora eu entenda a dor da codificação dupla, nós também apenas O Windows PowerShell 2.0 foi preterido , então não vamos otimizar para compatibilidade anterior com 2.0 daqui para frente. : \

Meus casos de uso:

• Importe o módulo PowerShell do Active Directory.
• Importe o módulo do Azure Active Directory PowerShell.
• Estabeleça uma sessão remota do PowerShell para o servidor Exchange 2010-2016 e importe a sessão.
• Estabeleça uma sessão remota do PowerShell para o Exchange Online e importe a sessão.
• Estabeleça uma sessão remota do PowerShell para o servidor Lync / Skype e importe a sessão,

Se você conseguir fazer com que todos eles e seus cmdlets funcionem no Windows, Linux e MacOS, serão considerados heróis.

Imagino que o módulo AD seja o mais difícil, já que atualmente faz parte do RSAT e é um snap-in, conforme explicado em comentários anteriores. Mas, ei, a equipe AD tem que seguir em frente!

Se tudo mais falhar, faça a sessão remota do PowerShell para um controlador de domínio ou outro computador Windows que tenha esses módulos e importe a sessão.

O remoting implícito

Import-Module AzureAD
Connect-AzureAD

Exceção não tratada: System.TypeLoadException: Não foi possível carregar o tipo 'System.Drawing.Icon' do assembly 'System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'.
em System.Windows.Forms.Form.Dispose (disposição booleana)
em System.ComponentModel.Component.Finalize ()
connect-azuread: Ocorreram um ou mais erros. (Não foi possível carregar o tipo 'System.Drawing.Drawing2D.InterpolationMode' do assembly 'System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'.): Não foi possível carregar o tipo 'S
ystem.Drawing.Drawing2D.InterpolationMode 'from assembly' System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a '.
Na linha: 1 caractere: 1
conectar-azuread
CategoryInfo: AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException
FullyQualifiedErrorId: Connect-AzureAD, Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Além disso, todo o aplicativo trava com a mensagem "powershell.exe parou de funcionar"

Mover isso do marco 6.0.0, pois não há trabalho adicional planejado para 6.0.0

@ SteveL-MSFT Você poderia esclarecer se possível - qual é o plano / cronograma da MSFT para adotar módulos de seus produtos para PowerShell Core 6.0?

Muitas equipes de produto não iniciarão nenhum trabalho de validação até chegarmos à versão final 6.0.0, então o foco é fazer isso e se envolver com as equipes de produto para iniciar a validação. Infelizmente, isso não acontecerá rapidamente, por isso não posso fornecer um cronograma no momento.

Com base nesse problema , há um plano para portar os módulos Active Directory / Exchange para o PowerShell v6? As ferramentas serão apenas Windows (uma vez que System.DirectoryServices.Protocols atualmente é executado apenas em Windows)?

@ j3vans CoreFX ainda tem API muito limitada e não espero que as equipes MSFT possam portar esses módulos. Podemos usar módulos do Windows via remoting.

O Install-Module SqlServer não pode ser instalado no Mac.

`` `Passos para reproduzir:
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 <strong i="8">@PSBoundParameters</strong>                                                                                                    +                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 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

Sobre o "Install-Module SQLServer" - este módulo destina-se apenas ao sistema Windows. Não há módulos Linux / Mac SQLPS nem SQLServer (ainda).

Agora, se você quiser tentar construir seus próprios comandos SQL Server PowerShell em sistemas não Windows, você pode instalar o "Microsoft.SqlServer.SqlManagementObjects" que será executado no Linux.

Consulte a postagem do meu blog para obter mais informações: http://www.maxtblog.com/2017/11/streamlining-sql-server-management-objects-smo-in-powershell-core/

este problema será resolvido por https://github.com/PowerShell/WindowsPowerShellCompatibilityPack , abra os problemas para módulos específicos lá

Há algum trabalho em andamento para ter um módulo funcional do Active Directory para PS 6?

Olá @apetitjean ,

Você pode postar a pergunta no link @ SteveL-MSFT acima. Dessa forma, ele pode ser rastreado corretamente.
:)

Nos vemos no MVP Summit!

Obrigado @MaximoTrinidad. Postar aqui foi exatamente minha intenção. Espero que @ SteveL-MSFT veja minha pergunta aqui.

Na verdade, até breve! :)

@apetitjean o plano é ser capaz de oferecer suporte ao módulo do Active Directory por meio do Pacote de Compatibilidade do Windows PowerShell. Provavelmente usaremos remoting implícito e talvez com JEA.

@ SteveL-MSFT O Pacote de Compatibilidade do Windows PowerShell será apenas para Windows, correto? Não acho que seja aceitável que um módulo do Active Directory funcione apenas no Windows. Se o plano é oferecer suporte temporário ao AD apenas no Windows até que as APIs do .NET Core necessárias sejam feitas x-plat, então estou bem com isso. Porém, o AD é usado para mais do que apenas ambientes Windows e a capacidade de construir automação no Linux (e macOS) usando o PowerShell não deve exigir a manipulação direta do .NET ou chamar outras linguagens de shell / script que podem oferecer suporte ao AD no Linux.

Pelo que entendi, o módulo Active Directory não está no PowerShell
Placa da equipe e deve ser completamente reescrita para funcionar com o PowerShell
Essencial.
Acho que o que Steve está falando é uma solução alternativa que deve funcionar até
a próxima versão do módulo AD.

O módulo AD atual tem requisitos PSSnapin que não funcionarão no PS Core de qualquer maneira, a menos que estejamos adicionando algum shim PSSnapin no Pacote de Compatibilidade do Windows PowerShell que eu não conheço ... a única maneira de um módulo AD seria reescrever. É por isso que estou incomodado @ SteveL-MSFT, dizendo que o módulo AD (embora seja de responsabilidade da equipe do SO, e não da equipe do PowerShell) teria suporte do Pacote de Compatibilidade do Windows PowerShell. Já havia uma necessidade crítica de refatorar o módulo para o núcleo, e se seu futuro está no Pacote de Compatibilidade do Windows PowerShell, então essa é a direção errada.

Estou com a opinião @markekraus . Eu realmente não sou a favor de usar o Pacote de Compatibilidade do Windows PowerShell e penso "... deve mantê-los separados !!".

Mas essa é minha opinião!
:)

Meu entendimento sobre o Pacote de Compatibilidade do Windows PowerShell é que ele contém tudo o que nunca será transferido.

A intenção do Pacote de Compatibilidade do Windows PowerShell é ajudar temporariamente os usuários existentes do Windows PowerShell a migrar para o PSCore6. O plano de longo prazo é ter módulos rodando nativamente no PSCore6, bem como em plataforma cruzada. Algumas equipes podem decidir que nunca irão migrar para o PSCore6 ou o farão, mas não investirão em torná-lo compatível com várias plataformas. O maior influenciador para ajudá-los a tomar a decisão _certa_ é o feedback do cliente (não a equipe do PowerShell, onde representamos o cliente).

Entendido. e para quem sente o que eu sinto:

https://windowsserver.uservoice.com/forums/304621-active-directory/suggestions/33496864-port-active-directory-module-to-powershell-core-an

e

https://windowsserver.uservoice.com/forums/304621-active-directory/suggestions/13350033-open-source-the-activedirectory-powershell-module

Se eu tiver scripts que tenham dependências em dlls de framework .Net, devo procurar uma versão de núcleo .Net dessas dependências via nuget e, em seguida, tentar portar o script para PS6? Não existe um "invólucro" para essas dependências, correto?

@ dudeNumber4 depende. Se for um assembly que o PSCore6 já inclui (e incluímos muitos), você não deve precisar fazer nenhuma alteração, a menos que se refira a uma dll específica por meio do caminho. Por exemplo, se você dependia de System.DirectoryServices.AccountManagement.dll usando anteriormente Add-Type para carregar, se você não especificou um caminho, ele deve funcionar.

@ dudeNumber4 depende. Se for um assembly que o PSCore6 já inclui (e incluímos muitos), você não deve precisar fazer nenhuma alteração, a menos que se refira a uma dll específica por meio do caminho. Por exemplo, se você dependia de System.DirectoryServices.AccountManagement.dll usando anteriormente Add-Type para carregar, se você não especificou um caminho, ele deve funcionar.

OK, apenas tentei New-Object System.Data.OleDb.OleDbConnection . _Não é possível encontrar o tipo_. No nuget, vejo algum tipo de porta que alega suporte para .Net Standard 2.0. Para portar o script, eu teria que adicionar uma restauração nuget dessa biblioteca, correto?

@ dudeNumber4 não incluímos esse assembly como parte do PSCore6 em si, então para usá-lo, você deve ser capaz de usar Install-Package para baixar esse nupkg em tempo de execução ou fazer manualmente e apenas incluir esse assembly com seu roteiro.

WebAdministration - o xWebAdministration é o substituto ou o WebAdministration será transferido?

@IanKemp esse módulo é propriedade da equipe do IIS, então não sei seus planos. No entanto, da última vez que minha equipe olhou para aquele módulo, alguns dos namespaces do .Net Framework necessários não estavam disponíveis no .Net Core, então até que isso acontecesse não funcionaria a menos que eles o reescrevessem