Archiv für den Monat: November 2018

Code like C# (oder so ähnlich)

Die PowerShell-Skriptsprache ist kein C# und soll es auch nicht sein. Trotzdem haben die Erfinder der Sprache ein paar syntaktische Ähnlichkeiten eingebaut, die Entwicklern, die in der Regel C# verwenden (wo sind alle die VB-Entwickler geblieben?), das Eingewöhnen etwas erleichtern sollen. Dazu gehört z.B. die Option Konstruktorargumente in runden Klammern übergeben zu können und die Kleinigkeit, dass eine Befehlszeile mit einem Semikolon enden kann, auch wenn dieses nicht benötigt wird.

Beim Anlegen von Objekten werden C#-Entwickler den new-Operator vermissen. Das Pendant ist das etwas sperrige New-Object-Cmdlet oder seit Version 5 die statische New-Methode des Type-Objekts. Mit Hilfe eines Alias und der optionalen Klammerschreibweise für Konstruktorargumente wird die PowerShell-Syntax der C#-Syntax dann doch verblüffend ähnlich.

Die Semikolons sind natürlich überflüssig. Was es definitiv nicht gibt ist ein Pendant zum using-Befehl in C# für den automatischen Aufruf von Dispose(). Solche Feinheiten dürften in einem PowerShell-Skript eher selten eine Rolle spielen. Und Variablen müssen wirklich nicht deklariert werden, sie sind aber trotzdem typsiert.

Module in einer Remote-Session global importieren am Beispiel von Office 365/Exchange Online

Der Zugriff auf Exchange bzw. Exchange Online (Office 365) erfolgt im Rahmen einer Remote-Session. Im ersten Schritt wird die Remote-Session angelegt, im zweiten Schritt wird ein Modul im Rahmen der Remote-Session lokal importiert, so dass alle Cmdlets aus dem Modul lokal als (Proxy-) Functions zur Verfügung stehen.

Hier ein kleines Beispiel.

Das ist alles in der offiziellen PowerShell/Office 365-Dokumentation ausführlich dokumentiert, z.B.

https://docs.microsoft.com/de-de/office365/enterprise/powershell/manage-office-365-with-office-365-powershell

Was aber, wenn man das Importieren des Remote-Moduls in ein Modul auslagern möchte? Auf einmal steht das Remote-Modul außerhalb des Moduls nicht mehr zur Verfügung.

Ich muss zugegeben, dass ich auf die Lösung nicht auf Anhieb gekommen bin (oft bin ich auch zu bequem, um es wirklich zu probieren). Sie besteht darin, dass temporäre Modul per Import-Module mit dem Parameter Global oder Scope global zu importieren. Dadurch steht es anschließend auch außerhalb des angelegten Moduls zur Verfügung.