Umgang mit generischen Listen (Teil 2)

Im ersten Teil „Umgang mit generischen Listen“ ging es um ein erstes Kennenlernen der generischen Liste. Beantwortet wurde auch die Frage warum man sie überhaupt braucht. Die Antwort war: Für das administrative Skripten bringen sie keine Vorteile und sollten daher auch nicht verwendet werden. Sie sind immer dann praktisch bzw. notwendig, wenn Programmcode aus einem C#-Programm in ein PowerShell-Skript umgesetzt werden soll, oder wenn eine Methode einer .NET-Assembly eine generische Liste als Parameterwert erwartet.

In diesem Teil geht es um die Typenbezeichnung, die die PowerShell bei einer generischen Liste verwendet.

Ausgangspunkt für das Beispiel ist ein von mir definierter Typ mit dem Namen WTToken.

Ob dieser Typ per class-Befehl definiert wird, aus einem C#-Programm stammt oder es ein ganz anderer Typ ist, etwa PSCustomObject, spielt keine Rolle.

Mit dem Typ wird als nächstes eine generische Liste per new()-Methode angelegt.

Damit gibt es eine Liste $Tokenlist, die nur Objekte vom Typ WTToken aufnehmen kann.

Übergebe ich eine andere Sorte von Wert, etwa eine Zahl, kommt es wie zu erwarten zu einer Fehlermeldung. Die Meldung selber ist aber etwas irritierend. Anstatt „Wrong type error“ lautet die Fehlermeldung: Für „Add“ und die folgende Argumenteanzahl kann keine Überladung gefunden werden: „1“.. ??? WTF;)

Die Fehlermeldung will uns Folgendes sagen: Es kann für den Typ, den der Wert (1 Argument) besitzt, der übergeben werden soll, keine Methodenvariante gefunden werden, die diesen Typ akzeptiert. Eigentlich ganz einfach.

Bis jetzt ist hoffentlich noch alles nachvollziehbar.

Im Folgenden wird es kurzzeitig etwas spezieller. Beim Herumexperimentieren mit generischen Listen erhielt ich die obige Fehlermeldung auch dann, wenn der Wert vom Typ WTToken war und damit passen sollte.

Nach ein wenig Herumprobieren kam ich eher per Zufall auf die Lösung. Die PowerShell fügt in die Typenbezeichnung auch den Pfad der Ps1-Datei ein, in der der Typ definiert wird. Vermutlich aus der Überlegung heraus, dass die Typenbezeichnung damit eindeutig wird, da es keine zwei identischen Pfade geben kann.

Legt man jetzt in der ISE ein neues Fenster an und kopiert den Skriptcode, der eben noch funktioniert hatte, in das neue Fenster, kommt es zu obigen Fehler, da die generische Liste einen Typ erwartet, in dem der Pfad des alten Skripts noch enthalten ist. Wird das Objekt in dem neuen Fenster angelegt, erhält sein Typnname nicht den alten Ps1-Pfad und es entsteht ein neuer Typ, der nicht mehr in die generische Liste eingefügt werden kann.

Ein „Problem“ ist dieses Verhalten in der Praxis natürlich nicht. Der Fehler kann nur beim Herumprobieren in der ISE auftreten, da hier Variablen globale Variablen sind und mit ihrem aktuellen Wert und vor allem Typ in jedem neuen Fenster automatisch verwendet werden.

Im Folgenden möchte ich noch einmal zeigen, wie sich das von mir beschriebene Verhalten nachvollziehen lässt.

Schritt 1:

Starte die ISE, gib den folgenden PowerShell-Code ein und speichere das Ganze in einer Datei, z.B. „Test.ps1“.

Führe das Ganze aus. Die Liste in der Variablen Tokenlist besitzt den Typ „System.Collections.Generic.List`1[[WTToken, ⧹E։⧹2017⧹Projekte⧹BoolscherService⧹test.ps1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]“ (der Ps1-Pfad lautet natürlich immer anders).

Schritt 2:

Lege in der ISE ein neues Fenster an und füge den folgenden Code ein

Führe das Ganze aus. Es kommt zu der besagten Fehlermeldung, da WToken jetzt eine Typenbezeichnung erhält, in der anstelle des Ps1-Pfades nur „\powershell“ enthalten ist. Auch wenn es nur eine Kleinigkeit ist, ist es damit ein anderer Typ.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.