PowerShell und NET Anhängigkeit

Seit längerer Zeit nutze ich, wann immer möglich, nur noch die PowerShell 7. Das geht leider noch nicht immer, da einige Module auf DLLs und Klassen zurückgreifen, die es noch nicht im .NET Core Framework gibt. Beim Wechsel von Powershell auf PSWH muss man aber schon noch mal genauer hinschauen, ob direkt verwendete .NET Klassen wie erwartet funktionieren. Denn auch da gibt es Unterschiede.

Beispiel mit NET 5

Für den Einsatz im Bereich Systemmonitoring oder End2End-Monitoring (z.B. End2End-HTTP) muss ich manchmal auf native .NET Klassen zugreifen. Auch Microsoft nutz solche Beispiele in ihrer Dokumentation. So findet sich auf folgender Webseite ein Codeschnipsel.

Der folgende Codeschnipsel verbindet sich mit dem AIP-Service und gibt den Namen des Ausstellers aus:

$PSVersionTable.psversion.ToString()
$request = [System.Net.HttpWebRequest]::Create("https://admin.na.aadrm.com/admin/admin.svc")
$request.GetResponse()
$request.ServicePoint.Certificate.Issuer

Die drei Zeilen können problemlos in der klassischen Powershell ausgeführt werden.

So kann ich sehr einfach die Erreichbarkeit einer Gegenstelle per HTTPS ermitteln und auch das Zertifikat überprüfen.

Beispiel mit NET Core

Ich habe dann den identische Code unter PowerShell 7 auf Basis von NET Core:

Hier ist die Ausgabe "leer". Der ServicePoint ist gefüllt aber das Property "Certificate" ist aber "$null".

Suche im MSDN

Da ich die Klasse "[System.Net.HttpWebRequest]" nutze, liegt es natürlich nahe, sich die Beschreibungen unter NET 5 und Net Core mal anzuschauen.

Auf beiden Seiten finde ich dann einen wichtigen Satz:


https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint.certificate?view=netcore-3.1#remarks

Damit erklärt sich das korrekte Verhalten der Powershell 7. Die Frage ist ehe, wie ich als Entwickler von PowerShell-Skripten damit umgehe. Eigentlich müsste man eine Liste der Klassen erstellen, in denen weggefallene Funktionen beschrieben werden. Damit könnte ich dann alle PS1-Dateien durchlaufen und problematische Skripte erkennen.

Die Frage stellt sich natürlich auch für "richtige" Entwickler, die C# o.ä. nutzen und beim Wechsel auf NET Core.

Eigentlich wäre es mir lieber gewesen, wenn die Eigenschaft komplett entfallen wäre. Dann könnte ein Compiler einen Fehler werfen und der Entwickler seinen Code anpassen. So muss ich mir angewöhnen, Rückgaben genauer zu analysieren.

Weitere Links