Laden...

Package Data Retrieval & License Analyzer

Erstellt von Palladin007 vor 10 Monaten Letzter Beitrag vor 10 Monaten 571 Views
Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 10 Monaten
Package Data Retrieval & License Analyzer

Guten Abend,

ich möchte ein kleines Projekt von mir vorstellen (und um Reviews bitten):

=== Link entfernt, da ich das Projekt vorerst privat gestellt habe ===

EDIT:
Ich werden das Projekt vorerst ruhen lassen.
Ich habe mir nach Abts Feedback alles nochmal durch den Kopf gehen lassen und ich werde das Projekt neu aufrollen, aber mit ein paar anderen Ansätzen.


Dieses Projekt stellt einen Code Generator zur Verfügung, um Informationen über installierte Packages und deren Abhängigkeiten im Code abzurufen. Es ermöglicht das umfassende Abrufen von Informationen über installierte Packages, einschließlich Abhängigkeiten, und generiert Code zum Zugriff auf diese Daten. Mit dem enthaltenen Analyzer kann die Einhaltung von Lizenzen sichergestellt werden.

Darüber hinaus ermöglicht es eine optionale Konfiguration, die Zugriff auf Icons, Lizenztexte, ReadMe-Inhalte, Versionshinweise und andere Informationen bietet. Es bietet die Flexibilität, diese zusätzlichen Ressourcen basierend auf den eigenen Anforderungen einzubeziehen.

Hauptfunktionen:

- Generieren von Code für einfachen Zugriff auf die Daten
- Analysieren und Durchsetzen der Lizenzkonformität
- Anpassbare Konfigurationseinstellungen
- Nahtlose Integration in bestehende Projekte

Beispiel, wie der generierte Code genutzt wird:

var serilog = PackagesProvider.GetPackageById("Serilog");

foreach (var package in PackagesProvider.GetPackages())
    Console.WriteLine($"{package.Id} | {package.Version.Value} | {package.License?.License}");

// Oder mit einer Instanz:

IPackagesProvider instance = new PackagesProvider();

var serilog = instance.GetPackageById("Serilog");

foreach (var package in instance.GetPackages())
    Console.WriteLine($"{package.Id} | {package.Version.Value} | {package.License?.License}");

Beachtet aber, dass nach der Installation oder einem Neustart von Visual Studio der Generator einige Sekunden braucht, um die Daten zu laden - je nach Einstellung. Im Anschluss sollten diese Daten zwischengespeichert werden, bis Visual Studio geschlossen und der Cache verworfen wird.


Ich verfolge mit diesem Thema nicht nur den Zweck einer Projektvorstellung, ich hoffe auch auf Meinungen, Wünsche, Ideen, Fragen und natürlich auch Kritik - vor allem Kritik 😃

Tests gibt es nur sehr wenig, da die pure Lauffähigkeit der Tests der wichtigste Test von allen ist. Ausführlichere Tests für einzelne Funktionen werde ich noch ergänzen.

Das Projekt selber sollte out the box laufen.
Start-Projekt muss "Loop8ack.PackagesProvider.Analyzer" sein, es gibt ein Launch Profile, das sowohl Generator als auch Analyzer inkl. Debugger für das Test-Projekt startet. Mit den fertigen NuGet-Packages (nuget.config mit artifacts-Ordner ist vorhanden) geht es natürlich auch, allerdings ist die Arbeit damit während der Entwicklung ein wenig ... umständlich, um es freundlich auszudrücken 😃

Wenn Ihr etwas ändern und testen wollt, müsst Ihr ggf. Visual Studio neustarten, da es die Binaries nach irgendeiner Regel unter Temp ablegt und dort wiederverwendet, sodass die Änderungen nicht übernommen werden.


Ich hoffe auf Feedback und Kritik und bedanke mich für Eure Zeit 😃

16.807 Beiträge seit 2008
vor 10 Monaten

Also ich find die Idee gut und auch der Aufbau vom Projekt gefällt mir im Großen und Ganzen.

Was mir nicht ganz gefällt ist, dass die Prüfung im Build erfolgt.
Das "verschlechtert" meine Developer Experience, weil es länger braucht.

Ich/wir verwenden so eine Prüfung zB mit Hilfe von WhiteSource - erfolgt also auf dem CI/CD System; nicht lokal.

Idee: mach das Ding als .NET Tool, das man als CLI einbinden kann. Das ist ein weit verbreitetes Vorgehen, zB bei OpenAPI, Swagger, NBGV...
Das .NET Tool kann dann als MSBuild Task eingehängt werden; hier Beispiel für Swashbuckle CLI.

<Target Name="OpenAPI" AfterTargets="Build" Condition="$(Configuration)=='Debug'">
    <Exec Command="dotnet swagger tofile --output ./wwwroot/openapi/v1/openapi.yaml --yaml $(OutputPath)$(AssemblyName).dll v1" 
          WorkingDirectory="$(ProjectDir)" />
    <Exec Command="dotnet swagger tofile --output ./wwwroot/openapi/v1/openapi.json $(OutputPath)$(AssemblyName).dll v1"
          WorkingDirectory="$(ProjectDir)" />
</Target>

Das würde dann sowohl im CI (CLI halt als Task ausführen) aber auch lokal/während des Builds.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 10 Monaten

Erst einmal danke für das Feedback 😃

Was mir nicht ganz gefällt ist, dass die Prüfung im Build erfolgt.
Das "verschlechtert" meine Developer Experience, weil es länger braucht.

Das stimmt, bei meinen Tests braucht der Analyzer aber nur 42ms?
Der Analyzer lädt auch gar nichtdie aufwändigen Daten, es sollte also immer ungefähr so schnell bleiben.
Der Generator braucht natürlich etwas länger, nachdem die Daten im Cache sind, aber nur wenig.

Wobei mein Test-Projekt aber nur 100 Packages umfässt (XUNit + Moq + Abhängigkeiten + .NET), in großen Projekten, wenn dort dutzende eigene Packages installiert werden, sieht das womöglich weniger rosig aus.

Idee: mach das Ding als .NET Tool, das man als CLI einbinden kann.

Die Idee gefällt mir, werde ich auf jeden Fall umsetzen, aber als .NET Tool und Analyzer, dann kann man es sich aussuchen.
Muss ich mich nur erst einmal einlesen, aber umständlicher als ein Analyzer wird's nicht sein 😄