WordpressIch schreibe meinen Blog hier schon immer zweisprachig, auf Deutsch und auf Englisch. Ganz früher war das noch mein eigener Webcode. Dann bin ich irgendwann auf WordPress umgestiegen. Und die Plugins für die mehrsprachigen Posts, etc., waren schon immer irgendwie … anstrengend.

Und jetzt hat mein bisheriges Plugin für den mehrsprachigen Blog vollends den Geist aufgegeben; vermutlich durch ein WP-Update oder PHP-Update. Wie auch immer. Hilft ja nix. Also, gibt’s jetzt mal wieder ein neues Plugin. Das verwaltet jetzt unterschiedliche Sprachen indem jeder Post genau eine Sprache hat, und dieselben Posts in unterschiedlichen Sprachen „nur“ verlinkt sind. Eigentlich ein ganz nettes Konzept.

Heißt aber auch das meine bisherigen Posts alle, wirklich alle, überarbeitet werden müssen, genau wie die Webseitenstruktur selbst und alle Extraseiten auch. Und das wird dauern.

Also, wird der Inhalt auf meiner Webseite bis auf weiteres immer so ein bisschen Kaputt aussehen. Tschuldigung.


Update 2024-09-15: während ich so dabei bin meine Blog-Artikel zu fixen, d.h. sie nach ihrer Sprache in zwei getrennte Artikel zu splitten, da merke ich dass Links zwischen den Artikeln dabei falsch sein können, im Besonderen bei den englischsprachigen Versionen. Sorry, aber mir ist dieses alte Zeug nicht wichtig genug, dass ich das durchgehend fixe…

Ich bin auf dieses Nuget gestoßen, weil ich WPF-UI-Anwendungen geschrieben habe und einen Folder-Picker brauchte. Irgendwer im Internet schlug vor, die WinForms-Dialoge zu verwenden. Ich hasse es irgendwie, zwei Frameworks zu verwenden. Und dann brachte jemand anderes das Nuget WindowsAPICodePack.Shell ins Spiel, mit seinen Klassen der Windows Common Dialogs, einschließlich der Möglichkeit zur Auswahl von Ordnern im File-Öffnen-Dialogfenster.

Also fing ich an, das Nuget zu benutzen. Irgendwann wies mich ein Freund darauf hin, dass das Nuget-Paket gar nicht wie ein offizielles Microsoft-Paket aussah, sondern wie ein Repackage, das irgendjemand gemacht hatte. Das brachte mich zum Nachdenken. Ich unterstelle niemandem böse Absichten, aber ich fand es sehr, sehr seltsam. Das offizielle Paket war . Und es gibt eine ganze Reihe von Paketen mit seltsamen Namen:

Ich mag das nicht. Selbst wenn keiner der Autoren böse Absichten hegt, gefällt mir das nicht, denn es riecht nach Betrug, Phishing und Schwachstellen. Tut mir leid, aber nein.

Also, wo ist das offizielle Paket? Es scheint verschwunden zu sein, deshalb gibt es die Repackages von Community-Mitgliedern. Warum ist es verschwunden? Keine Ahnung. Vielleicht wurde es bei einer halbautomatischen Bereinigung erwischt, da es verwaist war. Jemand behauptet es wäre Microsoft.Windows.SDK.Contracts ersetzt worden.

Letztendlich habe ich den Code in meinen Projekten ersetzt, indem ich entweder doch den WinForms-Dialog verwendet oder eine sehr kleine P/Invoke-Wrapper-Klasse geschrieben habe, die die Win32-API-Funktion direkt aufruft. Wen es interessiert, der kann sie sich gerne anschauen:

https://github.com/sgrottel/open-here/commit/9de68198e35f0f6dec9386372cc71bada54c2f5b

Die Moral von der Geschichte ist, dass ein Nuget-Paket nur so gut ist wie die Menschen, die es pflegen. Und ich meine Menschen, nicht Organisationen. Denn am Ende kommt es darauf an, ob eine einzelne Person dahinter steht und ihr Bestes geben will oder nicht.

GLM wurde in Version 1.0.0 veröffentlicht, und ich habe das Nuget-Paket entsprechend aktualisiert.

Dabei habe ich auch den Quellcode des Nuget-Pakets von Bitbucket nach Github umgezogen.

Ich bin mir nicht sicher, ob es sich lohnt, über die Aktualisierung von Nuget-Paketen zu schreiben. Ich würde eher sagen, das ist Business as usual. Aber dieser Fall hier ist etwas Besonderes, denn der GLM-Entwickler entschied sich für 1.0.0. Ich möchte zu diesem Anlass besonders gratulieren! Ich finde es peinlich, wie viele Projekte die „Schallmauer“ dieses Schrittes zu fürchten scheinen, um endlich von „Ich weiß nicht“ zu „Das ist irgendwie das, was ich machen wollte und es ist irgendwie in der ersten Version fertig.“ Zu gehen. Ich glaube, viele weitere Projekte sind reif und stabil genug, um diesen Schritt zu gehen. Aber sie tun es nicht. Ich weiß es nicht.

Dies ist mein erster Post im Jahr 2024, und erstaunlicherweise habe ich es geschafft, siebeneinhalb Monate lang nichts zu schreiben. Das sieht aus wie ein trauriger Rekord. Nun, es ist nicht so, dass ich in dieser Zeit nichts für die Community getan hätte. Es zeigt aber, dass meine Prioritäten woanders lagen als in diesem Blog. Aufgeben werde ich den hier aber nicht.

Jedenfalls möchte ich nicht einfach aufgebläht auflisten was ich gemacht habe, indem ich, z.B., mein Github-Journal abschreibe, denn das wäre einfach nur traurig. Wenn Ihr euch dafür interessieren, was in meinen Tiny Tools, Everything Search Client, Checkouts Overview, OpenHere, LittleStarter, MyToDoBoard, aktualisierten Nuget-Paketen, SimpleLog, etc. passiert ist, dann empfehle ich direkt einen Blick in mein Github-Profil zu werfen. Das ist dann wohl die unaufgeblähte Auflistung.

Also, für heute belasse ich es bei dieser kleinen, traurigen „I am still alive“-Nachricht.

Der EverythingSearchClient kann nun seine Suchergebnisse sortiert zurückgeben. Der entsprechende neue Release v0.4 ist auf Github und als NuGet-Packet verfügbar.

Die Funktion die Suchergebnisse sortiert zu liefern zu können war einfach einzubauen, da sie hauptsächlich im Everything-Service selbst implementiert ist. I musste nur die entsprechenden Flags für die Query-v2 Interprozess-Communications-Anfrage in meine CSharp-Client-Bibliothek übernehmen.

Damit habe ich nun keine aktuellen Pläne für weitere Funktionen in meinem EverythingSearchClient. Ich benutze die Library bereits in ein paar meiner eigenen Projekte. Wenn Ihr sie auch benutzt, dann würde ich mich freuen das zu hören. :-)

Rund um Lua und sein NuGet-Paket ist eine Menge passiert.

Lua 5.4.5 wurde veröffentlicht. Es war also Zeit für ein Update meines Lua NuGet Pakets. Und für eine Überraschung. Und für Schmerzen.

Am Ende wurde alles gelöst, und die neue Version des Lua NuGet-Pakets ist online.

Allerdings wurde der Lua-5.4.5-Release wieder entfernt, und hoffentlich kommt schnell Lua 5.4.6.

Update 20230514: Lua 5.4.6 is here!

Die Überraschung: Das Lua NuGet-Paket war nicht gelisted!?

Vor einigen Monaten haben meine Benachrichtigungen von Github aufgehört zu funktionieren. Keine Ahnung, warum. Aber da ich dort nicht viel Updates habe, war es für mich nie eine hohe Priorität, das zu fixen. Aus diesem Grund hätte ich dieses von Smurf-IV aufgeworfene Problem fast übersehen: „[Question] Why does nuget state that the packages have been witdrawn ?

Woot? Ich habe absolut keine Ahnung, was dort passiert ist. Aber ich habe eine Vermutung. Das NuGet-Paket wurde ursprünglich von der CoApp-Organisation erstellt. Irgendwann haben sie es jedoch nicht mehr aktualisiert. Als ich eine neuere Version von Lua benötigte, beschloss ich, selbst ein NuGet-Paket zu erstellen. Ich hatte bereits gute Erfahrungen mit der Erstellung nativer C++-NuGet-Pakete gemacht, also habe ich es ausprobiert, und es hat gut funktioniert. Zu diesem Zeitpunkt wandte ich mich an die CoApp-Organisation und fragte sie, ob ich das NuGet-Paket für Lua mitverfassen dürfte. Meine Idee war, dass ich dieses Paket unter Verwendung der schönen und präzisen NuGet-Paket-ID veröffentlichen könnte. Sie stimmten zu, gaben mir die Co-Autorenschaft, und seither veröffentliche ich NuGet-Pakete für jede Version von Lua.

Und nun wurde das Paket vom „Autor“ nicht mehr gelistet und als veraltet und mit kritischen Fehlern versehen gekennzeichnet. Was? Das kann ich Ihnen sagen, ich war es nicht!

Die Sache mit den „kritischen Fehlern“ hat mich ein wenig beunruhigt. In meinem früheren Job war ich auch damit beauftragt, unsere Codebasis regelmäßig auf CVEs zu überprüfen. Ich kenne also ein paar Dinge, auf die man achten muss. Ich habe einen schnellen Check für Lua gemacht, und ja, es gibt CVEs, aber nichts Ungewöhnliches. Nichts so Schwerwiegendes, dass das Paket so stark eingeschränkt werden müsste.

Und noch etwas wurde deutlich: Die CoApp-Org scheint überhaupt keine NuGet-Pakete mehr zu besitzen. Keines. Das ist ziemlich überraschend.

Also, meine Vermutung ist, dass die CoApp-Organisation auf NuGet vielleicht aufgelöst wurde, aber mit Sicherheit ihr Engagement für die Wartung der NuGet-Pakete eingestellt hat. Als Vorsichtsmaßnahme wurden alle NuGets abgeschaltet und vielleicht automatisch als veraltet und veraltet markiert. Bei der Sache mit den „kritischen Fehlern“ bin ich mir nicht sicher. Deshalb gehe ich von einer automatischen „Abschaltung“ aus, bei der wahllos alle Pakete markiert und aus der Liste entfernt wurden.

Nun, mein Commitment, das Lua-Nuget-Paket zu pflegen, bleibt bestehen!

Ich werde weiterhin Versions-Updates und ähnliches veröffentlichen. Deshalb habe ich die 5.4.x Versionen des Lua-Pakets (wieder) aufgelistet und die Warnhinweise, dass sie veraltet sind, veraltet sind oder kritische Fehler haben, entfernt. Über die Beweggründe der CoApp-Gruppe kann ich nur spekulieren. Aber das werde ich nicht tun.

Der Schmerz: Umzug von AppVeyor zu Github Actions

All dies geschah im Zuge der Veröffentlichung der Version 5.4.5 von Lua. Eine Aufgabe, die seit langem auf meiner ToDo-Liste steht, war die Migration und Konsolidierung der verschiedenen Code- und CI-Plattformen. Bis jetzt habe ich die verschiedenen Varianten von Lua für das NuGet-Paket auf AppVeyor gebaut. Und ich plante schon lange, diese Aufgabe auf Github Actions zu verlagern. Also habe ich beschlossen, dass jetzt endlich die Zeit ist, das zu tun. Ein Grund dafür ist ein bevorstehender Feiertag in Deutschland, der mir die zusätzliche Zeit verschafft hat, mich um diese Aufgabe zu kümmern.

Während Github-Aktionen für einfache Projekte ganz nett sind, und obwohl sie ziemlich leistungsfähig sind, stoße ich sofort auf ein Problem: Mein NuGet-Paket enthält auch Build-Flavors von älteren Visual C++-Tools, derzeit bis hinunter zu v120. Und auf der Runner-VM der GitHub-Aktionen sind nur das neueste Visual C++ und die neuesten Toolsets installiert.

Und so begann für mich eine lange Reihe von Versuchen und Fehlern. Eine Menge Schmerzen, Kopfschmerzen und „warum, warum, warum…“-Momente. Am Ende habe ich die folgenden Lösungen gefunden:

HowTo: Anpassen der Visual Studio 2022-Installation auf Github Actions Runner

Fangen wir einfach an. Der Github-Runner wird mit Visual Studio Enterprise 2022 installiert. Daher sollte die neueste Toolchain sofort funktionieren, nämlich Visual C++ v143, v142 und v141, und das hat sie auch. Nun zu der Toolchain v140, die über den Visual Studio Installer installiert werden kann. Das sollte also einfach sein. Nun, theoretisch ja. Der Visual Studio Installer bietet Befehlszeilenargumente zum Ändern einer Installation und zum Hinzufügen von Komponenten, und das ist es, was ich tun muss. Das einzige Problem ist, dass der Installer keine Konsolenanwendung ist. Wenn er gestartet wird, kehrt die aufrufende Konsole sofort zurück, so dass ein Job im Workflow Yaml nicht warten kann, zumindest nicht automatisch. Ich muss den Installer mit `Start-Process` aufrufen und dem Befehl explizit sagen, dass er auf das Ende des erzeugten Prozesses warten soll.

Wenn Sie den Installer lokal in einer Eingabeaufforderung, z. B. einer Powershell, ausführen, werden Sie Ausgabemeldungen sehen. Wenn Sie ihn auf Github CI ausführen, ist das nicht der Fall. Wie ich schon sagte, ist der Installer keine Konsolenanwendung. Als solche führt er wahrscheinlich eine manuelle Konsolen-Host-Verbindung durch, um seine Ausgabemeldungen einzuschieben. Und auf Github CI existiert der Konsolen-Host wahrscheinlich nicht, da die Prozessausgabe vom CI-Agentenprozess in eine temporäre Datei geleitet wird. Infolgedessen findet der Installer keinen Konsolenhost und gibt daher auch keine Ausgabemeldungen aus. Ich befinde mich im Blindflug. Um zu wissen, ob der Befehl erfolgreich war oder nicht, verwende ich „vs_installer.exe export“, um die Liste der installierten Komponenten auszugeben. Das ist nicht schön, aber gut genug für die manuelle Fehlersuche.

So, das hat funktioniert:

- name: Modify Visual Studio 2022
  if: matrix.toolConfig.vs2022addMod != ''
  shell: pwsh
  run: |
    $component = "${{matrix.toolConfig.vs2022addMod}}"
    Write-Host "Adding:" $component

    Start-Process -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList "modify","--add",$component,"--installPath","`"C:\Program Files\Microsoft Visual Studio\2022\Enterprise`"","--passive","--includeRecommended","--norestart","--noUpdateInstaller" -Wait

    Start-Process -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList "export","--config","info-post.txt","--installPath","`"C:\Program Files\Microsoft Visual Studio\2022\Enterprise`"","--passive","--noUpdateInstaller" -Wait
    Write-Host "VS2022 Components after modification:"
    Write-Host (gc info-post.txt)

    Write-Host "Added:"
    Write-Host (gc info-post.txt | Select-String $component)

HowTo: Visual Studio 2013 auf Github Actions Runner

Dies lässt mit dem Build mit der ältesten noch unterstützten Toolkette: v120 aka Visual Studio 2013, und das ist ein echter Schmerz! Ich kann es den meisten Leuten nicht verübeln, da dies eine über 10 Jahre alte Software ist. Ich würde für so etwas keinen Support geben wollen. Aber mit diesem NuGet-Paket tue ich es irgendwie doch.

Das aktuelle Visual Studio unterstützt diese Toolkette nicht. Ich brauche also eigentlich Visual Studio 2013. Fragen Sie das Internet, was zu tun ist, und es wird Ihnen sagen, Visual Studio 2013 zu installieren, z. B. die kostenlose „Expression“ Edition, über Chocolatey. Ich habe es versucht, und es schlug mit der kryptischsten Fehlermeldung aller Zeiten fehl:

„Exit code indicates the following: Generischer MSI-Fehler. Dies ist ein lokaler Umgebungsfehler, kein Problem mit einem Paket oder dem MSI selbst […]“ bla bla bla.

Es gibt eine Menge falscher Hinweise, was zu tun ist. Der eigentliche Grund ist ein ganz anderer: Das Paket lädt eigentlich nur den Bootstrap-Installer von Visual Studio herunter, etwa 1,2 MB. Der Rest des Pakets wird bei der Installation auf Anforderung heruntergeladen. Und genau da liegt das Problem. Microsoft hat diese alten Download-Quellen entfernt, da sie anfällig waren, weil sie mit SHA-1-Hashes signiert waren. Und damit sind jetzt alle Chocolatey-Pakete kaputt. … Ich könnte mich irren, aber die Auswirkungen und die spärlichen Informationen, die ich aus den Logdateien herausgeschnitten habe, sehen wirklich so aus.

Das heißt, ich brauche ein vollständiges Visual Studio 2013. Zu diesem Zeitpunkt ist es offiziell über Microsofts Download-Website my.visualstudio.com verfügbar. Nachdem ich mich angemeldet und durch eine dynamische Website geklickt habe, versteht sich. Für meine Automatisierungszwecke nicht akzeptabel. Also habe ich die DVD-ISO auf meinem OneDrive neu gehostet. Ich würde sagen, das ist ok, aber nicht ideal. Und jetzt muss ich auch noch das komplette Visual Studio 2013 installieren. Klingt teuer. Klingt mühsam. Klingt langsam. Klingt wie ein Job für Docker. … Nun, ja, aber leider würde ich ein Windows-Docker-Image benötigen, das einen Windows-Docker-Host benötigt, und das scheint auf Github noch nicht unterstützt zu werden. Also, ja, ich muss Visual Studio 2013 auf dem Runner installieren.

- name: Install VS 2013 tools
  if: matrix.toolConfig.toolset == 'v120'
  shell: pwsh
  working-directory: ${{env.GITHUB_WORKSPACE}}
  run: |
    Write-Host "Downloading VS 2013 Express for Windows Desktop (w Update 5) DVD ISO..."
    Invoke-WebRequest -Uri "${{ secrets.VS2013ISO_URL }}" -OutFile dvd.iso
    gci dvd.iso
    $dvdiso = (Resolve-Path .\dvd.iso).Path

    Write-Host "Mounting Disk..."
    $DiskImage = Mount-DiskImage -ImagePath $dvdiso -StorageType ISO -PassThru

    $volumeInfo = (Get-Volume -DiskImage $DiskImage)
    $volumeInfo

    cd ($volumeInfo.DriveLetter + ":\")
    gci

    Write-Host "Installing Visual Studio 2013 Express..."
    Start-Process -FilePath ($volumeInfo.DriveLetter + ":\wdexpress_full.exe") -ArgumentList "/Q","/NoRestart","/NoRefresh","/NoWeb","/Full" -Wait

    Write-Host "Unmounting Disk..."
    Dismount-DiskImage -DevicePath $DiskImage.DevicePath

Und das funktioniert. Und ist, wie erwartet, schmerzhaft langsam. Um den Overhead dieses Installationsschritts zu begrenzen, ist es sinnvoll, die Breite der Job-Matrix im Workflow zu verringern: nur einen Job für die Installation und danach alle Build-Schritte nacheinander ausführen. Im Endeffekt ist dies fast um den Faktor 4 schneller, als man aufgrund des massiven Installations-Overheads erwarten würde. Zum Glück für mich ist dieser Workflow kein Pull-Request-Blocker während der aktiven Entwicklung, sondern nur eine Release-Automatisierung.

Gedanken zum Abschluss

Letztendlich funktioniert die Migration zu Github-Aktionen. War es das wert? Ich meine, Lua wird etwa alle zwei Jahre veröffentlicht. Brauche ich dafür überhaupt CI? Und überhaupt, ist das native NuGet nicht tot, ersetzt durch andere Mittel, wie vcpkg, oder so?

Nun, all dies ist wahr. Ich habe dieses Unterfangen nicht weiterverfolgt, weil ich ein CI für mein Lua-NuGet-Paket haben wollte. Mein Hauptgrund ist „weil ich es kann“, oder eigentlich „weil ich es noch nicht kann“. Es war eine gute Gelegenheit, mein Github-Aktions-Fu zu verbessern. Meine Empfehlung an Sie: Wenn Sie eine solche Gelegenheit sehen, um zu lernen und Ihre Fähigkeiten zu verbessern, mit dem Vorteil, etwas Brauchbares daraus zu machen, tun Sie es.

Und, jetzt warte ich auf Lua 5.4.6 und vielleicht neue Überraschungen…