Archiv der Kategorie: Entwickler

Visual Basic-Code in einem PowerShell-Skript ausführen

Visual Basic ist ein wenig die vergessene Programmiersprache bei Microsoft. In den 90er Jahren hatte das damals noch alte Visual Basic einen großen Anteil daran, dass sich Windows 3.0 und seine Nachfolger als Betriebssystemoberfläche so schnell verbreiten konnte. Mit der Einführung von .NET Framework im Jahr 2002 war Visual Basic als Visual Basic.NET zwar noch vertreten, das neue Visual Basic hatte aber nicht mehr viel mit dem vertrauten Visual Basic gemein. Die Folge war, dass es immer mehr auf ein Abstellgleis geriet, wenngleich die Sprache immer noch ein fester Bestandteil des .NET Framework als auch von .NET Core ist und auch weiterentwickelt wird. Auch bei .NET Core 3.0 wird VB dabei sein, auch wenn es nicht für alle Anwendungstypen eingesetzt werden kann:

https://blogs.msdn.microsoft.com/vbteam/2018/11/12/visual-basic-in-net-core-3-0/

Anders sieht es bei PowerShell Core aus. Mit der aktuellen Version 6.1 wird VB im Zusammenhang mit dem Add-Type-Cmdlet nicht mehr unterstützt. Auch wenn es nur wenige Gründe geben dürfte, in einem PowerShell-Skript Visual Basic-Code zu verwenden ist es trotzdem etwas schade, da eine Option weniger zur Auswahl steht.

Das folgende Beispiel ist daher nur für die Windows PowerShell gedacht. Es startet Word per später Bindung, lädt eine Docx-Datei und speichert sie als Pdf-Datei. Das setzt Word ab Version 2010 (?) voraus, damit diese Option überhaupt zur Verfügung steht.

17 ist der „Code“ (der Wert der Konstanten, die für das Dateiformat steht) für Pdf. Alle Pfade bitte anpassen, damit es auch funktioniert.

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.

Die Beispiele zu meinem Vortrag auf der Basta! 2018

Die Basta! (der Name stand ursprünglich einmal für „Basic Tage“ – BASIC ist eine Programmiersprache, die vor allem in den 90er Jahren populär war – das Ausrufezeichen ist vermutlich aus Marketinggründen angehängt worden) ist zwar eine Entwicklerkonferenz, die zwei Mal im Jahr stattfindet (und das bereits seit über 20 Jahren), doch wie bei jeder Konferenz haben auch Randthemen ihren Platz.

Die Beispiele (in Gestalt einer Reihe von PowerShell-Skripten) gibt es unter dem folgenden Link:

Basta2018_PowerShellSkripte

Mehr zu dem Vortrag in Kürze (während ich diese Zeilen schreibe liegt er nämlich noch in der Zukunft und diese ist bekanntlich etwas schwierig vorauszusagen).

Tipps für Zwischendurch: COM-Methoden mit Enum-Werten aufrufen

Dieser Tipp ist etwas spezieller.

Ausgangspunkt ist eine COM-Dll (früher OLE Server oder COM Server genannt), die eine Methode Calculate anbietet, die drei Parameter besitzt. Der erste Parameter ist vom Typ eines Enum mit dem Namen „OpType“, die anderen beiden Parameter sind vom Typ int.

Das Anlegen eines COM-Objekts mit der ProgId ist einfach:

Der Aufruf von Calculate funktioniert zunächst nur, wenn für den Enum-Wert eine Zahl übergeben, z.B. eine 0.

Der Enum OpType ist zunächst nicht bekannt. Ein „Trick“ besteht darin, ihn per Enum-Befehl nachzubauen, den es ab Version 5.0 gibt.

Damit klappt auch der folgende Aufruf:

PowerShell Module schreiben – mit ein paar Tools geht es leichter

Das Schreiben eines PowerShell Moduls ist grundsätzlich nicht schwer. Im einfachsten Fall speichert man lediglich eine Ps1-Datei mit ein paar Functions als Psm1-Datei in ein leeres Verzeichnis und fertig ist das Modul. Möchte man es richtig machen, steckt eine Menge Arbeit dahinter (ich muss es wissen, denn in meiner Freizeit arbeite ich seit ein paar Wochen an meinem Osmium-Modul, das es in ein paar Wochen auf GitHub bzw. in der PowerShell Gallery geben wird).

Welche Tools Modulautoren unterstützen können, hat PowerShell-Experte David Christian in einem Blog-Eintrag zusammengestellt:

https://overpoweredshell.com//Tools-Module-Authors-Should-Leverage/

Kleine Tipps für Zwischendurch: C#-Code testen

Wer lediglich ein paar Zeilen C#-Code testen möchte, muss dafür nicht Visual Studio starten, um dort ein Projekt anlegen zu müssen, wenngleich dies natürlich kein allzu großer Aufwand ist und es mit Visual Studio Code einen Editor gibt, der vielsprachig ist. Es geht auch per PowerShell und dem vielseitigen Add-Type-Cmdlet. Über den MemberDefinition-Parameter wird der C#-Code für eine Membermethode übergeben. Name der Klasse und eventuell auch ein Namespace werden per Parameter festgelegt.

Das folgende Beispiel veranschauhlicht die einfache Vorgehensweise. Eventuell wäre eine statische Methode noch etwas kürzer.

PowerShell Core in einer Asp.Net Core-Anwendung hosten – die ersten Schritte

Gleich vorweg: Dies ist noch kein vollständiger Blog-Eintrag, es sind vielmehr nur mehr oder weniger zusammenhanglose Notizen, die allen weiterhelfen sollen, die an einem ähnlichen Projekt arbeiten und mir als eine Art „Notizzettel“ dienen sollen.

*** Letzte Aktualisierung: 11/11/2017 ***

Ich will in den nächsten Wochen ein umfangreicheres PowerShell-Skript über einen Websevice anbieten. Technisch ist das sehr einfach, wenn das Projekt auf ASP.NET basiert. Ich möchte das Projekt aber nur unter Asp.Net Core umsetzen, damit es theoretisch auch in einem Container unter Linux laufen kann. Warum nicht, auch wenn es für das Projekt im Moment keine konkreten Vorteile bietet?

Die Herausforderung besteht darin, dass PowerShell Core noch nicht immer nicht offiziell ist und es daher noch keine offiziellen Packages gibt. Ein Pendant zu System.Management.Automation ist das PowerShell Core SDK.

Einen guten Einstieg in die etwas komplizierte Thematik gibt der folgende Artikel:

https://github.com/PowerShell/PowerShell/tree/master/docs/host-powershell#net-core-sample-application

Im Folgenden beschreibe ich die Umsetzung des Projekts.

Ausgangspunkt ist ein leeres Verzeichnis. Vorausgesetzt werden VisuaL Studio Code (mit Visual Studio 2017 Community Edition ginge es zwar leichter, aber es soll ja nicht zu leicht sein) und die neueste Version des .NET Core SDKs, z.B. 2.02.

Die Downloaadresse ist https://www.microsoft.com/net/learn/get-started/windows

Schritt 1: Anlegen eines ASP.NET Core-Projekts vom Typ WebApi

Schritt 2:: Hinzufügen des PowerShell Core SDK-Package

*** Fortsetzung folgt ***

Nuget-Packages direkt laden

Nuget-Packages sind Paketdateien, die in der Regel Assembly-Dateien enthalten, die von Entwicklern für ihre Projekte verwendet werden. Seit Visual Studio 2012 werden solches Packages über die Paketverwaltung oder über das PowerShell-Konsolenfenster per Install-Package hinzugefügt.

In einem PowerShell-Skript benötigt man im Allgemeinen keine Packages. Wie immer gibt es Ausnahmen. Eine solche Ausnahme ist das sehr nützliche HtmlAgilityPack, das aus einer Assembly-Datei besteht, mit deren Hilfe sich die Inhalte einer Html-Seite per XPath und vertrauten XML-Methoden wie SelectNodes und SelectSingleNode ansprechen lassen.

Lee Holmes beschreibt die Technik des „Html Scraping“ mit Hilfe des HtmlAgilityPack sehr schön unter der folgenden Adresse:

http://www.leeholmes.com/blog/2010/03/05/html-agility-pack-rocks-your-screen-scraping-world/

Ich habe darüber auch bereits etwas geschrieben, aber wer den Artikel von Lee Holmes liest, weiß damit alles Wissenswerte und kann sich das Lesen anderer Blog-Einträge erst einmal sparen.

Bis auf eine Kleinigkeit eventuell: Normalerweise lädt man die Assembly-Datei von der Codeplex-Projektseite herunter. Es gibt zwei Gründe, die dagegen sprechen: Das Codeplex-Portal soll irgendwann in naher Zukunft eingestellt werden. Die Methode ist nicht besonders elegant, wozu gibt es das PackageManagement-Modul seit PowerShell 5.0?

Damit auch Nuget-Packages geladen werden, muss eine Package Source für die Adresse https://www.nuget.org/api/v2 existieren (dies ist zwar die „alte“ Adresse, sie funktioniert natürlich nach wie vor). Das Get-PackageSource-Cmdlet fragt diese ab:

Sollte die Package Source wider Erwarten noch nicht dabei sein, muss sie zuerst per Register-PackageSource angelegt werden:

Dabei muss auch der Providername, in diesem Fall Nuget angegeben werden. Das Ergebnis ist eine neue Package Source mit dem Namen „NugetP“.

Update: Offenbar ist die Installation von Nuget-Packages mit der Standard-Package-Source nicht möglich, da diese bereits auf der Version v3 basiert. Damit es funktioniert, muss in jedem Fall eine PackageSource mit dem v2-Feed registriert werden.

Damit kann das HtmlAgilityPack-Package per Install-Package-Cmdlet heruntergeladen werden:

Abgelegt wird das „Package“ mit seinen Dateien unter C:\Program Files\PackageManagement\NuGet\Packages. Die entscheidende Datei HtmlAgilitypack.dll befindet sich in einem der zahlreichen Unterverzeichnisse, z.B. unter HtmlAgilityPack.1.4.9.5\lib\Net45. Sie wird per Add-Type-Cmdlet und dessen Path-Parameter geladen.

Eine Alternative ist der direkte Aufruf von Nuget.exe, das zuerst per dir lokalisiert werden muss.

Sollte das aus irgendeinem Grund nicht funktionieren, kann es erforderlich sein, die Nuget-Paketquelle zuerst zu aktivieren:

Ein Nuget sources list listet alle vorhandenen Sources auf, ein Nuget list alle verfügbaren Pakete.