Powershell: FullCLR-Module nicht kompatibel mit PSCore6

Workflow ist nicht etwas, das wir unterstützen möchten. Stattdessen sind wir bestrebt, die Nebenläufigkeit/parallele Ausführung in PowerShell-Skripten zu verbessern, die unserer Meinung nach der Hauptgrund für die Verwendung von Workflows ist. Wenn es andere Gründe gibt, lassen Sie es mich wissen.

ConvertFrom-String setzt auf Technologie von Microsoft Research, die derzeit nicht als Open Source geplant ist.

Ich freue mich jedoch über das Feedback.

Workflow und ConvertFrom-String sind aus unterschiedlichen Gründen unabhängig voneinander, weshalb sie nicht in PSCore6 geplant sind. Ich würde zustimmen, dass ConvertFrom-String großartig gegen vorhandene textbasierte native Utils unter Linux funktionieren würde. Vielleicht können wir ein neues Cmdlet mit ähnlichen, aber einfacheren Funktionen wie ConvertFrom-String erstellen.

ConvertFrom-String oder ähnliche Funktionen wären äußerst nützlich

Ich habe die Auslastung des Windows PowerShell-Moduls unter Windows 10 Version 16215 mit installiertem RSAT überprüft.
Skript und Ergebnisse (einschließlich Fehler) in angehängter Datei.
4062a.txt
4062b.txt – vollständige Liste der Module von PowerShell Core.

Zusamenfassend.
Gesamtkernmodule = 12.
Windows- und Core-Module insgesamt = 120.
Windows-Module insgesamt = 108. ( In Windows Powershell Get-Module -ListAvailable).count = 109 )
Nach PowerShell Core Start - 3 Module geladen.
Nach dem Versuch, alle Module zu laden, sind 71 Module geladen.

Es werden also 59 von 108 Windows-Modulen geladen.
$fehler.count = 79

@iSazonov danke für diese Ergebnisse.

• Die CDXML-basierten Cmdlet-Fehler werden behoben, sobald wir zu einem neueren Dotnet-Kern mit diesem Fix wechseln.
• Ein Großteil der Fehler ist auf widersprüchliche Aliasnamen für DSC zurückzuführen.
• Das RemoteDesktop-Modul ruft Add-Type auf, was fehlschlägt und wir sollten das untersuchen
• Workflow eins wird voraussichtlich nicht funktionieren
• ISE one wird voraussichtlich nicht funktionieren
• ODataUtils gehört meinem Team und muss portiert werden cc @anmenaga

cc @PowerShell/powershell-committee

Oh, das ActiveDirectory-Modul ist PSSnapIn 😕 Die Hauptverbraucher von PowerShell Core (Systemadministratoren) werden über Bord geworfen!

Wir müssen mit diesem Team über das Umschreiben ihres Cmdlets sprechen...

Exchange Server 2013 EMS hat PowerShell Core zerstört. Es kann auch keine Exchange-Assemblys finden.

Das SCCM 2012 R2-Modul wird nicht geladen - .Net-Abhängigkeiten sind unterbrochen und es wurden keine Assemblys im lokalen (SCCM-Home-) Ordner gefunden.

Das Sharepoint 2013-Modul ist PSSnapIn.

Unter MacOS und Linux:

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

Get-Container

Datei oder Assembly 'Docker.DotNet, Version=2.124.0.0, Culture=neutral, PublicKeyToken=null' konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.
In Zeile:1 Zeichen:1

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

Schließe ich also richtig aus den obigen Kommentaren ab, dass ActiveDirectory nicht funktioniert, weil es ein PSSnapIn, kein Modul ist und diese Version keine Snapins unterstützt?

Auch wenn ich Import-Module -Name MSOnline konnte, als ich Connect-MsolService versuchte, bekam ich eine "Konnte den Typ 'System.Drawing.Drawing2D.InterpolationMode' aus der Assembly 'System.Drawing' nicht laden, dann stürzte powershell.exe ab.

@JakeMoe Ja, PSSnapIn ist in PowerShell Core veraltet.

System.Drawing ist nicht in CoreFS und .Net Standard 2.0 enthalten.

@iSazonov könnten Sie diese drei (Exchange, SharePoint und SCCM) noch einmal mit Beta.4 ausprobieren? Vielen Dank!

Und danke an alle anderen, macht weiter so!

PS C:\Programme\PowerShell\6.0.0-beta.4> Import-Modul MSOnline
Import-Module : Typ 'System.Diagnostics.EventLogEntryType' konnte nicht aus Assembly 'System, Version=4.0.0.0, geladen werden,
Kultur=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 - geladene, einfache Cmdlets funktionieren
• Sharepoint - geladene, einfache Cmdlets funktionieren
• SCCM - NullReferenceException und Absturz:

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

• Skype Server 2015 - Typ 'System.Management.Automation.PSSnapIn' konnte nicht geladen werden.

Ich habe erneut die Auslastung des Windows PowerShell-Moduls unter Windows 10 ver 162241 mit installiertem
Skript und Ergebnisse (einschließlich Fehler) in angehängter Datei.

4062Beta4fulllist.txt
4062Beta4ipmoall.txt - vollständige Liste der Module von PowerShell Core.

Zusamenfassend.
Gesamtkernmodule = 12.
Windows- und Core-Module insgesamt = 125.
Windows-Module insgesamt = 113.
Nach PowerShell Core Start - 2 Module geladen.
Nach dem Versuch, alle Module zu laden, werden 108 Module geladen.

Es werden also 96 von 113 Windows-Modulen geladen.
$fehler.count = 47

habe eines meiner benutzerdefinierten Skripte mit Beta 4 überprüft, aber es bricht mit einem Fehler ab:
catch:function : Prozess: Fehler:Ausnahme beim Aufrufen von ".ctor" mit "0"-Argument(en): " Der Typ 'System.Diagnostics.PerformanceCounter '

geöffnet #4295

Bearbeitet von @daxian-dbw:
Die Hauptursache ist, dass System.Diagnostics.PerformanceCounter derzeit nicht in .NET Core verfügbar ist. dotnet/corefx#3906 verfolgt die Unterstützung von PerformanceCounter in .NET Core jedoch mit dem Meilenstein "Zukunft" gekennzeichnet, was bedeutet, dass sie in .NET Core 2.0 nicht verfügbar sein wird.
Weitere Informationen finden Sie unter #4295.

@mi-hol Bitte neue Issue-Frage öffnen.

Get-WUList funktioniert nicht in 6.0 Core Beta-4 von PSWindowsUpdate Version 1.6.0.3 . Unter Windows 10 Desktop PowerShell funktioniert es einwandfrei.

Ausgabe:

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 Danke für deinen Bericht!
Ich habe PSWindowsUpdate getestet.

• Sie haben ein Problem mit Test-Connection und WS-Management. Bitte diskutieren Sie dies nicht im Thema - öffnen Sie eine neue Problem-Frage, wenn Sie Hilfe benötigen.
• Wir können PSWindowsUpdate weiterhin nicht verwenden, da #3775 .

Sowohl WebAdministration als auch IISAdministration werden in PS Core nicht ausgeführt, da sie erwarten, dass GAC-Assemblys verfügbar sind. Die Verwendung von DSC ist wahrscheinlich eine bessere Alternative, aber die Anwendung der Konfiguration im Kern ist aufgrund des Fehlens von Invoke-DSCResource und Start-DSCConfiguration umständlich. siehe #4457.

Jedes Update auf Problem, MsOnline-Modul kann nicht auf Linux-basiertem Betriebssystem importiert werden . #4269

Invoke-MySqlQuery aus der PowerShell-Galerie funktioniert nicht. Ich erhalte eine Fehlermeldung, wenn ich versuche, es in Beta 5 unter Windows 10 zu verwenden. Mein Verständnis des .Net-Standards war, dass dies möglicherweise unter Windows funktioniert (natürlich nicht unter Linux/Mac). Die Assembly wird geladen, es wird nur ein Fehler bei einer der häufigsten darin enthaltenen Methoden angezeigt.
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."

Ich habe auch ein internes Modul, das das gleiche Problem mit Conn.Open() hat. Wir verwenden das interne Modul, um eine Verbindung zu Hunderten von MySql-Servern und auch zu AWS Aurora herzustellen.

Dies geschieht sowohl mit Connector/Net 6.9.9 als auch mit Connector/Net 8.0.8 (auf verschiedenen Computern installiert). Es funktioniert in früheren Versionen von PowerShell ohne Probleme.

@FireInWinter Danke für deinen Bericht! Bitte öffnen Sie ein neues Problem mit Schritten, um das Problem zu reproduzieren.

Wir müssen in der Lage sein, Formulare zu präsentieren. Idealerweise über System.Drawing, aber bei Bedarf könnte ich einige in XAML konvertieren. Beides funktioniert jedoch nicht, ist also etwas Grafisches mit Powershell tot? Wir werden nie zu PowershellCore wechseln, wenn wir keine Form verwenden können. Und nein, wir werden C# nicht verwenden :P

Kann man auch mit Sicherheit sagen, dass Get-WmiObject tot ist? Ich wünschte, die Syntax zwischen Get-WmiObject und Get-CimInstance wäre identisch, aber das ist nicht der Fall, sodass Sie gezwungen sind, zweimal zu codieren, wenn Sie noch PS 2.0 haben.

@agressiv wir haben einige Untersuchungen für https://github.com/PowerShell/PowerShell/issues/3957 im Gange, um GUIs zu aktivieren

Get-WmiObject gilt als veraltet. @joeyaiello hat gerade einen Blog darüber gepostet, dass wir PSv2 offiziell

Wir haben immer noch Maschinen mit 2.0, weil Microsoft WMF 4.0 auf vielen Kernprodukten nur langsam unterstützte und unsere Migration abgeschlossen ist. Wir müssen einen weiteren Pass machen, um zu sehen, wer noch übrig ist, da wir jetzt aufgefordert werden, 5.1 bereitzustellen (was natürlich nicht mit fast allem kompatibel ist, einschließlich Skype und Exchange Server).

Gibt es eine Liste von Cmdlets wie Get-WmiObject, die entfernt werden und auf die wir verweisen können?

Was ist die Zielplattform für WinPE? Wird es auch in den Kern verschoben? Auch dort verwenden wir Windows Forms.

Ich habe einen Dump aller Cmdlets in der 6.0 Beta gemacht und einfach ein Vergleichsobjekt erstellt. hier sind die für uns:

• Alle EventLog-Cmdlets. Diese nutzen wir ausgiebig.
• Test-ComputerSecureChannel.
• Add-PSSnapin. Ich würde dies gerne nicht verwenden, aber anscheinend haben viele Module faule Autoren. (zB Vmware, WSUS, MDT, Citrix, SCOM, Dell). Vielleicht gibt es andere Möglichkeiten, einige dieser Module zu laden, aber diese OEMs verwenden Add-PSSnapin tatsächlich in ihrem Code - also ändern wir entweder ihren Code in der Hoffnung, dass er funktioniert, oder sie ändern ihn endlich. Natürlich hätten sie Add-PSSnapin schon seit 8 Jahren nicht mehr verwenden sollen, aber manche Dinge ändern sich nie.

@agressiv VMware PowerCLI ist jetzt ein Modul, das aus der PowerShell-Galerie installiert werden kann, und ich bin mir fast sicher, dass sie damit bereits PowerShell Core unterstützen (das müsste ich jedoch noch einmal überprüfen). Es gibt jedoch noch andere PSSnapin-Nachzügler, wie Sie betonen.

@agressiv für PSCore6 haben wir die Unterstützung für PSSnapins absichtlich entfernt. VMWare hat jedoch einen Port von PowerCLI für PSCore6 , der sich derzeit nicht in PSGallery befindet

@aggresiv : An der UI-Front geben wir die GUI-Bemühungen definitiv nicht ganz auf, wir sind uns nur noch nicht sicher, wohin die Reise geht. Wenn Sie auf https://github.com/PowerShell/Phosphor vorbeischauen, können Sie sich ein Experiment ansehen, das wir durchführen, um zu versuchen, webbasierte Benutzeroberflächen zu generieren (die viele der Probleme mit unterschiedlichen "nativen" Benutzeroberflächen vermeiden Frameworks, aber wenn jemand Qt-Bindungen für PowerShell erstellen möchte, würde mich das auch sehr freuen).

Was Get-WmiObject : Sie haben Recht, wir haben nicht vor, es zurückzubringen. Meiner Meinung nach hat Get-CimInstance die Syntax als Get-WmiObject Get-CimInstance immens verbessert (ein Grund, warum sie überhaupt erstellt wurde), und obwohl ich den Schmerz der Doppelcodierung verstehe, haben wir auch einfach veraltete Windows PowerShell 2.0 , daher werden wir in Zukunft keine Optimierung für die Rückkompatibilität zu 2.0 vornehmen. :\

Meine Anwendungsfälle:

• Importieren Sie das Active Directory PowerShell-Modul.
• Importieren Sie das Azure Active Directory PowerShell-Modul.
• Richten Sie eine Remote-PowerShell-Sitzung mit dem Exchange 2010-2016-Server ein und importieren Sie die Sitzung.
• Richten Sie eine Remote-PowerShell-Sitzung mit Exchange Online ein und importieren Sie die Sitzung.
• Richten Sie eine Remote-PowerShell-Sitzung mit dem Lync/Skype-Server ein und importieren Sie die Sitzung.

Wenn Sie all diese und ihre Cmdlets unter Windows, Linux und MacOS zum Laufen bringen können, werden Sie als Helden gefeiert.

Ich stelle mir das AD-Modul als das härteste vor, da es derzeit Teil von RSAT und ein Snap-In ist, wie in früheren Kommentaren erläutert. Aber hey, das AD-Team muss mit der Zeit gehen!

Wenn alles andere fehlschlägt, führen Sie eine Remote-PowerShell-Sitzung zu einem Domänencontroller oder einem anderen Windows-Computer mit diesen Modulen durch und importieren Sie dann die Sitzung.

@KeeperB5 implizites Remoting durch Importieren einer PSSession sollte nur mit PSCore6 funktionieren (Windows sowieso, habe es nicht mit Linux/MacOS versucht, sollte aber funktionieren)

Import-Modul AzureAD
Connect-AzureAD

Nicht behandelte Ausnahme: System.TypeLoadException: Der Typ 'System.Drawing.Icon' konnte nicht aus der Assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' geladen werden.
at System.Windows.Forms.Form.Dispose(Boolesche Entsorgung)
bei System.ComponentModel.Component.Finalize()
connect-azuread : Ein oder mehrere Fehler sind aufgetreten. (Der Typ 'System.Drawing.Drawing2D.InterpolationMode' konnte nicht aus der Assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' geladen werden.): Der Typ 'S . konnte nicht geladen werden
ystem.Drawing.Drawing2D.InterpolationMode' aus der Assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
In Zeile:1 Zeichen:1
connect-azuread
CategoryInfo : AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException
FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Außerdem stürzt die gesamte Anwendung mit der Meldung "powershell.exe funktioniert nicht mehr" ab.

Verschieben dieses Meilensteins aus 6.0.0, da keine zusätzlichen Arbeiten für 6.0.0 geplant sind

@SteveL-MSFT Könnten Sie klären, ob es möglich ist - was ist der MSFT-Plan/die Zeitleiste, um Module ihrer Produkte für PowerShell Core 6.0 zu übernehmen?

Viele Produktteams werden erst mit der Validierung beginnen, wenn wir die endgültige Version 6.0.0 erreichen. Daher liegt der Schwerpunkt darauf, dies zu erledigen und mit den Produktteams zusammenzuarbeiten, um mit der Validierung zu beginnen. Dies wird leider nicht so schnell passieren, daher kann ich derzeit keine Zeitleiste bereitstellen.

Gibt es aufgrund dieses Problems einen Plan, die Active Directory/Exchange-Module auf PowerShell v6 zu portieren? Werden die Tools nur Windows sein (da System.DirectoryServices.Protocols derzeit nur unter Windows läuft)?

@j3vans CoreFX hat immer noch eine sehr begrenzte API und ich erwarte nicht, dass MSFT-Teams diese Module portieren können. Wir können Windows-Module per Remoting verwenden.

Install-Module SqlServer wird nicht auf dem Mac installiert.

```Schritte zur Reproduktion:
Install-Modul 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

Über "Install-Module SQLServer" - Dieses Modul ist nur für Windows-Systeme gedacht. Es gibt (noch) keine Linux/Mac SQLPS- oder SQLServer-Module.

Wenn Sie nun versuchen möchten, Ihre eigenen SQL Server PowerShell-Befehle auf Nicht-Windows-Systemen zu erstellen, können Sie "Microsoft.SqlServer.SqlManagementObjects" installieren, das unter Linux ausgeführt wird.

Weitere Informationen finden Sie in meinem Blogbeitrag: http://www.maxtblog.com/2017/11/streamlining-sql-server-management-objects-smo-in-powershell-core/

Dieses Problem wird von https://github.com/PowerShell/WindowsPowerShellCompatibilityPack behoben. Öffnen Sie dort bitte Probleme für bestimmte Module

Wird an einem funktionsfähigen Active Directory-Modul für PS 6 gearbeitet?

Hallo @apetitjean ,

Sie können die Frage unter dem obigen Link @SteveL-MSFT posten. Auf diese Weise kann es richtig verfolgt werden.
:)

Wir sehen uns beim MVP-Gipfel!

Danke @MaximoTrinidad. Hier zu posten war genau meine Absicht. Ich hoffe, @SteveL-MSFT wird meine Frage hier sehen.

Bis bald! :)

@apetitjean der Plan ist es, das Active Directory-Modul über das Windows PowerShell Compatibility Pack unterstützen zu können. Höchstwahrscheinlich werden wir implizites Remoting verwenden und vielleicht mit JEA.

@SteveL-MSFT Windows PowerShell Compatibility Pack wird nur Windows sein, richtig? Ich glaube nicht, dass es akzeptabel ist, dass ein Active Directory-Modul nur unter Windows funktioniert. Wenn der Plan ist, AD vorübergehend nur unter Windows zu unterstützen, bis die erforderlichen .NET Core-APIs x-plat gemacht sind, bin ich damit einverstanden. AD wird jedoch nicht nur für Windows-Umgebungen verwendet, und die Möglichkeit, mit PowerShell Automatisierung in Linux (und macOS) zu erstellen, sollte keine direkte .NET-Manipulation oder Aufrufe anderer Shell-/Skriptsprachen erfordern, die AD unter Linux unterstützen können.

Nach meinem Verständnis befindet sich das Active Directory-Modul nicht in der PowerShell
Die Platte des Teams und sie sollte komplett neu geschrieben werden, um mit PowerShell zu funktionieren
Kern.
Ich denke, was Steve meint, ist ein Workaround, der funktionieren sollte, bis
das nächste AD-Modul-Release.

Das aktuelle AD-Modul hat PSSnapin-Anforderungen, die in PS Core sowieso nicht funktionieren, es sei denn, wir fügen einige PSSnapin-Shim im Windows PowerShell Compatibility Pack hinzu, die mir nicht bekannt sind ... die einzige Möglichkeit für ein AD-Modul wäre ein Neuschreiben. Aus diesem Grund bin ich bei @SteveL-MSFT gestört, dass das AD-Modul (obwohl es in der Verantwortung des Betriebssystemteams und nicht des PowerShell-Teams liegt) vom Windows PowerShell Compatibility Pack unterstützt würde. Es bestand bereits ein kritischer Bedarf für eine Neugestaltung des Moduls für den Kern, und wenn seine Zukunft im Windows PowerShell Compatibility Pack liegt, dann ist das die falsche Richtung.

Ich bin mit @markekraus Meinung. Ich bin wirklich nicht für die Verwendung des Windows PowerShell Compatibility Packs und denke "... es sollte sie getrennt halten!".

Aber das ist meine Meinung!
:)

Mein Verständnis von Windows PowerShell Compatibility Pack war, dass es alles enthält, was nie portiert werden wird.

Die Absicht des Windows PowerShell Compatibility Packs besteht darin, bestehenden Windows PowerShell-Benutzern vorübergehend zu helfen, zu PSCore6 zu wechseln. Der langfristige Plan ist es, Module nativ auf PSCore6 auszuführen und plattformübergreifend zu sein. Einige Teams entscheiden möglicherweise, dass sie niemals auf PSCore6 portieren werden oder dies tun, aber nicht in die plattformübergreifende Kompatibilität investieren. Der größte Einflussfaktor, der ihnen hilft, die _richtige_ Entscheidung zu treffen, ist das Kundenfeedback (nicht das PowerShell-Team, in dem wir den Kunden vertreten).

Verstanden. und für alle, die so denken wie ich:

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

und

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

Wenn ich Skripte habe, die Abhängigkeiten von .Net-Framework-DLLs haben, sollte ich über Nuget nach einer .Net-Kernversion dieser Abhängigkeiten suchen und dann versuchen, das Skript auf PS6 zu portieren? Es gibt keinen "Wrapper" für diese Abhängigkeiten, richtig?

@dudeNumber4 es kommt darauf an. Wenn es sich um eine Assembly handelt, die PSCore6 bereits enthält (und wir viele davon enthalten), sollten Sie keine Änderungen vornehmen müssen, es sei denn, Sie verweisen über den Pfad auf eine bestimmte DLL. Wenn Sie beispielsweise von System.DirectoryServices.AccountManagement.dll abhängig waren, das zuvor Add-Type zum Laden verwendet hat, sollte es einfach funktionieren, wenn Sie keinen Pfad angegeben haben.

@dudeNumber4 es kommt darauf an. Wenn es sich um eine Assembly handelt, die PSCore6 bereits enthält (und wir viele davon enthalten), sollten Sie keine Änderungen vornehmen müssen, es sei denn, Sie verweisen über den Pfad auf eine bestimmte DLL. Wenn Sie beispielsweise von System.DirectoryServices.AccountManagement.dll abhängig waren, das zuvor Add-Type zum Laden verwendet hat, sollte es einfach funktionieren, wenn Sie keinen Pfad angegeben haben.

OK, gerade versucht New-Object System.Data.OleDb.OleDbConnection . _Typ kann nicht gefunden werden_. Auf Nuget sehe ich eine Art Port, der die Unterstützung für .Net Standard 2.0 beansprucht. Um das Skript zu portieren, müsste ich eine Nuget-Wiederherstellung dieser Bibliothek hinzufügen, richtig?

@dudeNumber4 Wir schließen diese Assembly nicht als Teil von PSCore6 selbst ein. Um sie zu verwenden, sollten Sie Install-Package , um dieses Nupkg zur Laufzeit herunterzuladen, oder dies manuell tun und diese Assembly einfach in Ihre einfügen Skript.

WebAdministration - ist xWebAdministration der Ersatz oder wird WebAdministration portiert?

@IanKemp Dieses Modul gehört dem IIS-Team, daher kenne ich ihre Pläne nicht. Als sich mein Team das letzte Mal dieses Modul angesehen hat, waren jedoch einige der erforderlichen .Net Framework-Namespaces in .Net Core nicht verfügbar. Bis dahin würde es nicht funktionieren, es sei denn, sie schreiben es neu