Archiv der Kategorie: Entwickler

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.