Powershell: Módulos FullCLR no compatibles con PSCore6

El flujo de trabajo no es algo que planeemos respaldar. En su lugar, nos comprometemos a mejorar la experiencia de ejecución simultánea / paralela en el script de PowerShell, que creemos que es la razón principal por la que la gente usa los flujos de trabajo. Si hay otras razones, avíseme.

ConvertFrom-String se basa en tecnología de Microsoft Research que actualmente no está planeada para ser de código abierto.

Sin embargo, agradezco los comentarios.

Workflow y ConvertFrom-String son independientes con diferentes razones por las que no están planeados para estar en PSCore6. Estoy de acuerdo en que ConvertFrom-String funcionaría muy bien contra las utilidades nativas basadas en texto existentes en Linux. Quizás podamos crear un nuevo cmdlet con una capacidad similar, pero más simple, a ConvertFrom-String.

ConvertFrom-string, o una funcionalidad similar, sería extremadamente útil

Verifiqué la carga del módulo de Windows PowerShell en Windows 10 ver 16215 con RSAT instalado.
Script y resultados (incluidos errores) en archivo adjunto.
4062a.txt
4062b.txt : lista completa de módulos de PowerShell Core.

En breve.
Total de módulos básicos = 12.
Total de módulos de Windows y Core = 120.
Total de módulos de Windows = 108. (En Windows Powershell Get-Module -ListAvailable) .count = 109)
Después del inicio de PowerShell Core: se cargan 3 módulos.
Después de intentar cargar todos los módulos, se cargan 71 módulos.

Entonces se cargan 59 de 108 módulos de Windows.
$ error.count = 79

@iSazonov gracias por obtener esos resultados.

• Los errores de cmdlet basados ​​en CDXML se solucionarán una vez que nos traslademos al núcleo dotnet más nuevo que tenga esta solución .
• La mayoría de los errores se deben a alias conflictivos para DSC.
• El módulo RemoteDesktop está llamando a Add-Type que falla y deberíamos investigar eso
• Se espera que el flujo de trabajo uno no funcione
• Se espera que ISE uno no funcione
• ODataUtils es una propiedad de mi equipo que necesita ser transferida cc @anmenaga

cc @ PowerShell / comité-de-powershell

Oh, el módulo ActiveDirectory es PSSnapIn 😕 ¡Los principales consumidores de PowerShell Core (administradores del sistema) están tirados por la borda!

Tendremos que hablar con ese equipo sobre la reescritura de su cmdlet ...

Exchange Server 2013 EMS aplastó PowerShell Core. Además, no puede encontrar ensamblados de Exchange.

El módulo SCCM 2012 R2 no está cargado: dependencias .Net rotas y no se encuentran ensamblados en la carpeta local (inicio de SCCM).

El módulo de Sharepoint 2013 es PSSnapIn.

En MacOS y Linux:

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

Get-Container

No se pudo cargar el archivo o ensamblado 'Docker.DotNet, Version = 2.124.0.0, Culture = neutral, PublicKeyToken = null'. El sistema no puede encontrar el archivo especificado.
En línea: 1 carácter: 1

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

Entonces, ¿infiero correctamente de los comentarios anteriores que ActiveDirectory no funciona porque es un PSSnapIn, no un módulo, y esta versión no admite complementos?

Además, aunque pude Import-Module -Name MSOnline, cuando probé Connect-MsolService, obtuve un "No se pudo cargar el tipo 'System.Drawing.Drawing2D.InterpolationMode' del ensamblaje 'System.Drawing', luego powershell.exe se bloqueó.

@JakeMoe Sí, PSSnapIn está en desuso en PowerShell Core.

System.Drawing no está en CoreFS y .Net Standard 2.0.

@iSazonov, ¿ podrías probar esos tres (Exchange, SharePoint y SCCM) nuevamente con beta.4? ¡Gracias!

Y gracias a todos los demás, ¡sigan viniendo!

PS C: \ Archivos de programa \ PowerShell \ 6.0.0-beta.4> Módulo de importación MSOnline
Import-Module: no se pudo cargar el tipo 'System.Diagnostics.EventLogEntryType' del ensamblaje 'Sistema, versión = 4.0.0.0,
Cultura = 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: los cmdlets simples cargados funcionan
• Sharepoint: los cmdlets simples cargados funcionan
• SCCM - NullReferenceException y bloqueo:

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

• Skype Server 2015: no se pudo cargar el tipo 'System.Management.Automation.PSSnapIn'.

Volví a comprobar la carga del módulo de Windows PowerShell en Windows 10 ver 162241 con RSAT instalado.
Script y resultados (incluidos errores) en archivo adjunto.

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

En breve.
Total de módulos básicos = 12.
Total de módulos de Windows y Core = 125.
Total de módulos de Windows = 113.
Después del inicio de PowerShell Core: se cargan 2 módulos.
Después de intentar cargar todos los módulos, se cargan 108 módulos.

Entonces se cargan 96 de 113 módulos de Windows.
$ error.count = 47

Verifiqué uno de mis scripts personalizados con Beta 4 pero aborta con un error:
catch: function : Process: Error: Excepción llamando ".ctor" con "0" argumento (s): " No se pudo cargar el tipo 'System.Diagnostics.PerformanceCounter ' del ensamblaje 'Sistema, Versión = 4.0.0.0, Cultura = neutral, PublicKeyToken = b77a5c561934e089 '. "

abrió # 4295

Editado por @ daxian-dbw:
La causa principal es que System.Diagnostics.PerformanceCounter actualmente no está disponible en .NET Core . dotnet / corefx # 3906 está rastreando el soporte de PerformanceCounter en .NET Core pero está marcado con el hito 'Futuro', lo que significa que no estará disponible en .NET Core 2.0 .
Consulte el número 4295 para obtener más información.

@ mi-hol Por favor, abra un nuevo problema-pregunta.

No se puede hacer que Get-WUList funcione en 6.0 core beta-4 desde PSWindowsUpdate versión 1.6.0.3 . Funciona bien en Windows 10 Desktop PowerShell.

Producción:

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 ¡ Gracias por tu informe!
Probé PSWindowsUpdate.

• Tiene un problema con Test-Connection y WS-Management. Por favor, no discuta esto en el tema - abra un nuevo Problema-Pregunta si necesita ayuda.
• Todavía no podemos usar PSWindowsUpdate porque # 3775.

Tanto WebAdministration como IISAdministration no se ejecutan en PS Core porque esperan que los ensamblados de GAC estén disponibles. Usar DSC es probablemente una mejor alternativa, pero aplicar la configuración en el núcleo es incómodo debido a la falta de Invoke-DSCResource y Start-DSCConfiguration . ver # 4457.

Cualquier actualización en cuestión, no puedo importar el módulo MsOnline en un sistema operativo basado en Linux . N.º 4269

Invoke-MySqlQuery de la Galería de PowerShell no funciona. Recibo un error cuando trato de usarlo en Beta 5 en Windows 10. Mi entendimiento de .Net Standard era que existe la posibilidad de que esto funcione en Windows (no en Linux / Mac, por supuesto). El ensamblaje se carga, solo obtiene un error en uno de los métodos más comunes.
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."

También tengo un módulo interno que tiene el mismo problema en Conn.Open (). Usamos el módulo interno para conectarnos a cientos de servidores MySql y también a AWS Aurora.

Esto sucede tanto con Connector / Net 6.9.9 como con Connector / Net 8.0.8 (instalados en diferentes computadoras). Funciona en versiones anteriores de PowerShell sin problemas.

@FireInWinter ¡ Gracias por tu informe! Abra un nuevo problema con los pasos para reproducir el problema.

Necesitamos poder presentar formas. Idealmente, a través de System.Drawing, pero si es necesario, podría convertir algunos a XAML. Sin embargo, ninguno de los dos funciona, entonces, ¿hay algo gráfico con Powershell muerto? Nunca pasaremos a PowershellCore si no podemos usar algún tipo de formulario. Y no, no vamos a usar C #: P

Además, ¿es seguro decir que Get-WmiObject está muerto? Desearía que la sintaxis entre Get-WmiObject y Get-CimInstance fuera idéntica, pero no lo son, por lo que se ve obligado a codificar dos veces si todavía tiene PS 2.0.

@agressiv tenemos algunas investigaciones en curso para https://github.com/PowerShell/PowerShell/issues/3957 para habilitar las GUI

Get-WmiObject se considera obsoleto. @joeyaiello acaba de publicar un blog sobre nosotros desaprobando formalmente

Todavía tenemos máquinas en 2.0 porque Microsoft tardó en admitir WMF 4.0 en muchos productos principales y nuestra migración ha terminado. Tendremos que hacer otra pasada para ver quién queda, ya que ahora se nos pide que implementemos 5.1 (que, por supuesto, no es compatible con casi todo, incluidos los servidores de Skype y Exchange).

¿Existe una lista de cmdlets como Get-WmiObject que se eliminará y que podamos consultar?

¿Cuál es la plataforma de destino para WinPE? ¿Se moverá también al núcleo? Allí también usamos Windows Forms.

Hice un volcado de todos los cmdlets en la versión beta de 6.0 y simplemente hice un objeto de comparación. aquí están los para nosotros:

• Todos los cmdlets de EventLog. Los usamos ampliamente.
• Test-ComputerSecureChannel.
• Add-PSSnapin. Me encantaría no usar esto, pero aparentemente muchos módulos tienen autores perezosos. (por ejemplo, Vmware, WSUS, MDT, Citrix, SCOM, Dell). Quizás hay otras formas de cargar algunos de estos módulos, pero estos OEMS son los que realmente usan Add-PSSnapin en su código, por lo que estamos modificando su código, esperando que funcione, o finalmente lo cambian. Por supuesto, no deberían haber usado Add-PSSnapin desde hace 8 años, pero algunas cosas nunca cambian.

@agressiv VMware PowerCLI es ahora un módulo que se puede instalar desde la Galería de PowerShell, y estoy casi seguro de que ya son compatibles con PowerShell Core (aunque tendría que volver a comprobarlo). Sin embargo, hay otros rezagados de PSSnapin, como usted señala.

@agressiv para PSCore6, eliminamos deliberadamente el soporte para PSSnapins. Sin embargo, VMWare tiene un puerto de PowerCLI para PSCore6 que no está actualmente en PSGallery

@aggresiv : En el frente de la interfaz de usuario, definitivamente no estamos abandonando los esfuerzos de la GUI por completo, simplemente no estamos seguros exactamente de hacia dónde nos dirigimos todavía. Si visita https://github.com/PowerShell/Phosphor , puede consultar un experimento que estamos realizando para intentar generar interfaces de usuario basadas en la web (que evitan muchos de los problemas relacionados con la interfaz de usuario "nativa" dispar frameworks, aunque si alguien quiere hacer algunos enlaces Qt para PowerShell, eso también me haría muy feliz).

En cuanto a Get-WmiObject : tienes razón, no tenemos planes de traerlo de vuelta. En mi opinión, Get-CimInstance mejoró inmensamente en la sintaxis como Get-WmiObject (parte de la razón por la que se hizo en primer lugar), y aunque entiendo el dolor de la doble codificación, también simplemente Windows PowerShell 2.0 en desuso , por lo que no vamos a optimizar para la compatibilidad con versiones anteriores a 2.0 en el futuro. : \

Mis casos de uso:

• Importar el módulo de PowerShell de Active Directory.
• Importar el módulo PowerShell de Azure Active Directory.
• Establezca una sesión remota de PowerShell en el servidor Exchange 2010 - 2016 e importe la sesión.
• Establezca una sesión remota de PowerShell en Exchange Online e importe la sesión.
• Establezca una sesión remota de PowerShell en el servidor Lync / Skype e importe la sesión,

Si puede hacer que todos esos y sus cmdlets funcionen en Windows, Linux y MacOS, se le anunciará como un héroe.

Me imagino que el módulo AD es el más difícil, ya que actualmente es parte de RSAT y un complemento, como se explicó en comentarios anteriores. Pero bueno, ¡el equipo de AD tiene que seguir con los tiempos!

Si todo lo demás falla, realice una sesión remota de PowerShell en un controlador de dominio u otra computadora con Windows que tenga estos módulos y luego importe la sesión.

@ KeeperB5 La comunicación remota implícita al importar una PSSession debería funcionar con PSCore6 (Windows de todos modos, no lo he probado con Linux / MacOS, pero debería funcionar)

Módulo de importación AzureAD
Conectar-AzureAD

Excepción no controlada: System.TypeLoadException: no se pudo cargar el tipo 'System.Drawing.Icon' del ensamblaje 'System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'.
en System.Windows.Forms.Form.Dispose (eliminación booleana)
en System.ComponentModel.Component.Finalize ()
connect-azuread: se produjeron uno o más errores. (No se pudo cargar el tipo 'System.Drawing.Drawing2D.InterpolationMode' del ensamblaje 'System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'.): No se pudo cargar el tipo 'S
ystem.Drawing.Drawing2D.InterpolationMode 'del ensamblaje' System.Drawing, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a '.
En línea: 1 carácter: 1
conectar-azuread
CategoryInfo: AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException
FullyQualifiedErrorId: Connect-AzureAD, Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Además, toda la aplicación se bloquea con el mensaje "powershell.exe ha dejado de funcionar".

Sacar esto del hito 6.0.0 ya que no hay trabajo adicional planeado para 6.0.0

@ SteveL-MSFT ¿Podría aclarar si es posible: cuál es el plan / cronograma de MSFT para adoptar módulos de sus productos para PowerShell Core 6.0?

Muchos equipos de productos no comenzarán ningún trabajo de validación hasta que lleguemos a una versión final 6.0.0, por lo que el objetivo es lograrlo e interactuar con los equipos de productos para comenzar la validación. Desafortunadamente, esto no sucederá rápidamente, por lo que no hay un cronograma que pueda proporcionar en este momento.

En base a este problema , ¿hay algún plan para migrar los módulos de Active Directory / Exchange a PowerShell v6? ¿Las herramientas serán solo para Windows (ya que System.DirectoryServices.Protocols actualmente se ejecuta solo en Windows)?

@ j3vans CoreFX todavía tiene una API muy limitada y no espero que los equipos de MSFT puedan portar estos módulos. Podemos utilizar módulos de Windows a través de la comunicación remota.

Install-Module SqlServer no se instala en Mac.

`` `Pasos para reproducir:
Instalar módulo 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

Acerca de "Install-Module SQLServer": este módulo está destinado únicamente al sistema Windows. No hay módulos SQLPS ni SQLServer para Linux / Mac (todavía).

Ahora, si desea intentar crear sus propios comandos de SQL Server PowerShell en sistemas que no sean Windows, puede instalar "Microsoft.SqlServer.SqlManagementObjects", que se ejecutará en Linux.

Consulte la publicación de mi blog para obtener más información: http://www.maxtblog.com/2017/11/streamlining-sql-server-management-objects-smo-in-powershell-core/

este problema será abordado por https://github.com/PowerShell/WindowsPowerShellCompatibilityPack , abra los problemas para módulos específicos allí

¿Hay algún trabajo en progreso para tener un módulo de Active Directory funcional para PS 6?

Hola @apetitjean ,

Es posible que desee publicar la pregunta en el enlace @ SteveL-MSFT anterior. De esta manera se puede rastrear correctamente.
:)

¡Nos vemos en la MVP Summit!

Gracias @MaximoTrinidad. Publicar aquí era exactamente mi intención. Espero que @ SteveL-MSFT vea mi pregunta aquí.

¡Nos vemos pronto! :)

@apetitjean, el plan es poder admitir el módulo de Active Directory a través del paquete de compatibilidad de Windows PowerShell. Lo más probable es que usemos la comunicación remota implícita y quizás con JEA.

@ SteveL-MSFT El paquete de compatibilidad de Windows PowerShell será solo para Windows, ¿correcto? No creo que sea aceptable que un módulo de Active Directory funcione solo en Windows. Si el plan es admitir temporalmente la compatibilidad con AD solo en Windows hasta que las API de .NET Core requeridas se conviertan en x-plat, entonces estoy de acuerdo con eso. Pero, AD se usa para más que solo entornos de Windows y la capacidad de construir automatización en Linux (y macOS) usando PowerShell no debería requerir la manipulación directa de .NET o llamar a otros lenguajes de shell / scripting que pueden admitir AD en Linux.

Según tengo entendido, el módulo de Active Directory no está en PowerShell
La placa del equipo y debería reescribirse por completo para que funcione con PowerShell
Centro.
Creo que Steve está hablando de una solución que debería funcionar hasta que
la próxima versión del módulo AD.

El módulo AD actual tiene requisitos de PSSnapin que no funcionarán en PS Core de todos modos, a menos que agreguemos alguna corrección de PSSnapin en el Paquete de compatibilidad de Windows PowerShell que no conozco ... la única forma de un módulo AD sería una reescritura. Es por eso que estoy molesto @ SteveL-MSFT diciendo que el módulo AD (aunque es responsabilidad del equipo del sistema operativo, y no del equipo de PowerShell) sería compatible con el Paquete de compatibilidad de Windows PowerShell. Ya existía una necesidad crítica de refactorizar el módulo para el núcleo, y si su futuro está en el Paquete de compatibilidad de Windows PowerShell, entonces esa es la dirección equivocada.

Estoy con la opinión de @markekraus . Realmente no estoy a favor de usar el Paquete de compatibilidad de Windows PowerShell y creo que "... ¡debería mantenerlos separados!".

¡Pero esa es mi opinión!
:)

Mi comprensión del Paquete de compatibilidad de Windows PowerShell fue que contiene todo lo que nunca se trasladará.

La intención del Paquete de compatibilidad de Windows PowerShell es ayudar temporalmente a los usuarios existentes de Windows PowerShell a migrar a PSCore6. El plan a largo plazo es que los módulos se ejecuten de forma nativa en PSCore6 y que sean multiplataforma. Algunos equipos pueden decidir que nunca se trasladarán a PSCore6 o lo harán, pero no invertirán en hacerlo compatible con plataformas cruzadas. El mayor factor de influencia para ayudarlos a tomar la decisión _correcta_ es la retroalimentación de los clientes (no el equipo de PowerShell donde representamos al cliente).

Comprendido. y para quien se sienta como yo:

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

y

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

Si tengo scripts que tienen dependencias en .Net framework dlls, debería buscar una versión .Net core de esas dependencias a través de nuget y luego intentar portar el script a PS6. No hay un "contenedor" para estas dependencias, ¿correcto?

@ dudeNumber4 depende. Si se trata de un ensamblado que PSCore6 ya incluye (y nosotros incluimos muchos), entonces no debería necesitar hacer ningún cambio a menos que se refiera a una dll específica a través de la ruta. Por ejemplo, si dependía de System.DirectoryServices.AccountManagement.dll que anteriormente usaba Add-Type para cargar, si no especificó una ruta, debería funcionar.

@ dudeNumber4 depende. Si se trata de un ensamblado que PSCore6 ya incluye (y nosotros incluimos muchos), entonces no debería necesitar hacer ningún cambio a menos que se refiera a una dll específica a través de la ruta. Por ejemplo, si dependía de System.DirectoryServices.AccountManagement.dll que anteriormente usaba Add-Type para cargar, si no especificó una ruta, debería funcionar.

De acuerdo, acabo de intentar New-Object System.Data.OleDb.OleDbConnection . _No se puede encontrar el tipo_. En nuget, veo algún tipo de puerto que afirma ser compatible con .Net Standard 2.0. Para portar el script, tendría que agregar una restauración nuget de esa biblioteca, ¿correcto?

@ dudeNumber4 no incluimos ese ensamblado como parte de PSCore6, por lo que para usarlo, debería poder usar Install-Package para descargar ese nupkg en tiempo de ejecución, o hacerlo manualmente y solo incluir ese ensamblado con su texto.

WebAdministration: ¿es xWebAdministration el reemplazo o se transferirá WebAdministration?

@IanKemp ese módulo es propiedad del equipo de IIS, así que no conozco sus planes. Sin embargo, la última vez que mi equipo miró ese módulo, algunos de los espacios de nombres de .Net Framework necesarios no estaban disponibles en .Net Core, por lo que hasta que eso suceda no funcionará a menos que lo reescriban