Projektvorstellung: PackScan

Hallo zusammen,

Ich möchte Euch mein Projekt PackScan vorstellen, das die Handhabung von NuGet-Paketen erleichtert.

Kurz gesagt, PackScan ist ein Code-Generator, der die project.assets.json ausliest und sowohl die darin enthaltenen Daten als auch die Informationen aus den NuGet-Paketen selbst in Code umwandelt. Darüber hinaus kann es konfiguriert werden, um Texte und Icons aus dem Internet zu holen und in den Code zu integrieren. Dies erleichtert es, alle genutzten Pakete und Lizenzen im Blick zu halten und auf anschauliche Weise in der Anwendung darzustellen – eine Anforderung, die in früheren Projekten von mir aufkam.

Hier die Highlights:

• Automatische Sammlung von Informationen der verwendeten Pakete.
• Analyse der Lizenzen und Warnungen bei unerwünschten Lizenzen.
• Verfügbar als .NET Tool und Source-Generator für MSBuild.
• Umfangreiche Konfigurationsmöglichkeiten für individuelle Anpassungen und Performance-Optimierung.

Ich freue mich auf eure Meinungen, Vorschläge und Kritik! Bitte hinterlasst eure Kommentare hier oder auf der GitHub-Seite des Projekts.

Beste Grüße

Hi,

ich find das ne ziemlich gute Idee und ich finds auch ziemlich gut umgesetzt! Respekt.

Angenommen ich würde das nun in mehrere CI-CD Pipelines einbauen, wie hast Du Dir gedacht, dass das Setup zentral gemanaged werden könnte?
Verwende ich dann Env Vars mit Semicolon Values? Oder primär über ein Shared File, das dann in jedem Repo liegt?

Danke für das Lob 😃

Angenommen ich würde das nun in mehrere CI-CD Pipelines einbauen, wie hast Du Dir gedacht, dass das Setup zentral gemanaged werden könnte?

Das Projekt bietet ja einen SourceGenerator oder ein .NET Tool an, beide können MSBuild-Eigenschaften lesen. Das .NET Tool bietet zusätzlich noch eigene Parameter an, die dann die MSBuild-Eigenschaften überschreiben.

Du könntest deine zentrale Verwaltung der Einstellungen also mit Hilfe einer props-Datei lösen und in jedem Projekt einbinden.

Wenn die mehreren Projekte aber zusammengehören, solltest Du aber nur für das Start-Projekt der Code generiert lassen, da dieses Projekt als einziges alle Referenzen hat. Das Ergebnis kann man dann über Dependency Injection verteilen und dort nutzen, wo man es tatsächlich braucht.

Ich habe soeben die erste Version hochgeladen.

Ich habe soeben Version 0.3.0 hochgeladen:

v0.3.0 - 2023-11-13

Hinzugefügt

• PackScan.Tool-Parameter, um das TargetFramework für das Projekt anzugeben.
• PackScan.Tool-Parameter, um den RuntimeIdentifier für das Projekt anzugeben.
• Funktion, um die maximale Größe für heruntergeladene Icons im Format "<Breite>x<Höhe>" festzulegen.

v0.2.1 - 2023-11-06

Behoben

• Ein Fehler wurde behoben, der Probleme mit spezifischen Plattformversionen verursachte, wie sie in MAUI-Projekten verwendet werden.

v0.2.0 - 2023-11-01

Hinzugefügt

• Neue Konfigurationsoption, die es ermöglicht, Inhalte nur aus Dateien zu laden, wenn keine URL angegeben ist und umgekehrt.

Hi.

Ich hab aktuell einen Kunden, der so ein Tool sucht und hab ihm das hier gezeigt.
Sein Feedback war:

• Das Setup des Tools ist zu aufwändig, die Readme zu lang (was auch immer das heisst)
• Das Sample auf GitHub funktioniert nicht

dotnet package-tools generate-packages-provider --output PackagesProvider --load-mode onlyfile --content-write-mode Embed --clear-output True
Could not execute because the specified command or file was not found.

• Du verwendest mit ImageSharp eine Dependency, wie bei kommerzieller Verwendung eine Lizenz erfordert; nicht sofort ersichtlich (könnte man vielleicht raus machen bzw. als Tool-Plugin machen?)

Ich hab mir das hier jetzt nochmal genauer angeschaut, und gebe ihm teilweise recht - weiß aber nicht, obs einfacher geht und hab hier auch keinen produktiven Vorschlag; nur Feedback.

Es wäre toll, wenn dieses Tool stand-alone alle Anhängigkeiten scannen und sowohl in einer Baum- wie auch in einer Tabellen-Ansicht alle Abhängigkeiten zeigen würde.
Baum: zeigt alle Dependencies und Sub-Dependencies.
Tabelle: zeigt nur explizit genutzte Pakete mit Lizenzen im Projekt / Solutionweit.

Hi,

danke für das Feedback.

Das Setup des Tools ist zu aufwändig, die Readme zu lang

Das ist ggf. dem geschuldet, dass es viel tut 😄
Mir ist gerade auch nicht ganz klar, wie ich damit umgehen sollte.
Ggf. reicht es aus, wenn ich mehrere Wiki-Seiten erstelle, die die spezialisierteren Fälle dann weiter beleuchten und in der ReadMe steht nur das wichtigste.

Das Sample auf GitHub funktioniert nicht

Korrigiere ich, sobald ich dazu komme, danke.

Du verwendest mit ImageSharp eine Dependency, wie bei kommerzieller Verwendung eine Lizenz erfordert; nicht sofort ersichtlich (könnte man vielleicht raus machen bzw. als Tool-Plugin machen?)

Das wird verwendet, wenn man Package-Bilder hinzufügen lässt.
Diese Bilder können teilweise ziemlich groß sein, ImageSharp rechnet die klein.

Ein Plugin wäre eine gute Option, aber dazu müsste ich mir erst Mal Gedanken machen, wie ich das mit der Projekt-Struktur behandle, da bin ich nicht ganz zufrieden mit und plugin-fähig ist sie auch nicht.

Ggf. könnte ich auf diese Weise auch das Problem mit den (zu) vielen Funktionen angehen, indem ich das ganze Projekt in einzelne Plugins aufsplitte und dann separat beschreibe.

Aber das muss ich mir erst einmal in Ruhe durch den Kopf gehen lassen.

Es wäre toll, wenn dieses Tool stand-alone alle Anhängigkeiten scannen und sowohl in einer Baum- wie auch in einer Tabellen-Ansicht alle Abhängigkeiten zeigen würde.

Das ist ja eigentlich das Ziel 😃 Nur dass man die Ansicht alleine bauen muss/kann, mein Tool macht nur die Rohdaten im Code verfügbar.
Stand-alone ist natürlich eine valide Anforderung, aber leider nicht mal eben so gemacht, ohne das Feature mit den Bildern ganz raus zu streichen, oder in Kauf zu nehmen, dass viel zu große Bilder embedded werden.

Gibt es beim Kunden eine Deadline?

Du kennst das ja ggf. auch, 15 Projekte auf der Pipeline, aber arbeiten kann man nur an einem Projekt gleichzeitig 😄

Zitat von Palladin007

Das ist ggf. dem geschuldet, dass es viel tut 😄
Mir ist gerade auch nicht ganz klar, wie ich damit umgehen sollte.

Wie wärs mit einem simplen Default Output?

Oder Doku nach Use-Case, sodass das Komplexe vom Einstieg abstrahiert ist.

Das ist ja eigentlich das Ziel 😃 Nur dass man die Ansicht alleine bauen muss/kann, mein Tool macht nur die Rohdaten im Code verfügbar.

Wäre praktisch, wenn das in der Console direkt (zB via Spectre) verfügbar is, sodass das Simple eben sofort da ist und eigene Sachen für das Komplexe da ist.

Gibt es beim Kunden eine Deadline?

Ja. Kam heute zu mir weil heute die Deadline ist 😄 Kein Stress.

Habs jetzt per Hand gemacht. Waren 78 Referenzen.
Für seine Frontend App muss ichs nachher noch (ebenfalls von Hand) machen.

Wie wärs mit einem simplen Default Output?

Der Output ist ja immer der gleiche ^^
Der Plan war ja, dass man dann im Code sämtliche Informationen hat, wie man sich so vorstellen kann, damit man anschließend selber die UI aufbauen und entsprechend filtern kann. Ansonsten habe ich die Problematik, dass ich Filter-Optionen konfigurierbar machen muss und das wird eklig ^^

Unterschiede gibt es, wenn man zusätzliche Inhalte (ReadMe, Icons, etc.) laden will, darauf fallen dann auch ein Großteil der Einstellungen an.
Der Rest sind dann die Lizenzprüfung und sowas wie Klassenname, public vs. internal, etc.
Wenn ich das Laden von zusätzlichen Inhalten und die Lizenzprüfung herausziehen kann (Doku und/oder technisch), dann wird die Doku schon deutlich einfacher.

Das Problem mit der Dependency auf ImageSharp kann ich aber nur mit einem Plugin-System lösen.

Abgesehen davon wäre ggf. auch ein JSON-Output ein Gedanke wert, spricht ja eigentlich nichts gegen.

Wäre praktisch, wenn das in der Console direkt (zB via Spectre) verfügbar is, sodass das Simple eben sofort da ist und eigene Sachen für das Komplexe da ist.

Hm - damit könnte man das CLI-Tool direkt mit einer UI ausstatten, kann es aber weiterhin automatisiert laufen lassen - gefällt mir.

Das würde ich dann aber weiter aufziehen, da das Tool ja eigentlich nicht für die einmalige Anwendung gedacht ist, sondern dass es permanent bei jedem Build läuft und man das ganze Thema auch für die Zukunft vom Tisch hat.
Ich würde es dann so aufbohren, dass man (auch) eine JSON-Config aufbauen und über die UI bearbeiten/speichern kann. Bei erneuter Ausführung würde es dann die JSON-Config lesen.

Ja. Kam heute zu mir weil heute die Deadline ist 😄

Also wieder sehr frühzeitig, ich fühle mit dir 😄