Laden...

coreArgs - Ein Parser für Kommandozeilen Argumente unter .NET Standard

Erstellt von Geaz vor 7 Jahren Letzter Beitrag vor 7 Jahren 4.466 Views
Geaz Themenstarter:in
148 Beiträge seit 2013
vor 7 Jahren
coreArgs - Ein Parser für Kommandozeilen Argumente unter .NET Standard

Hallo zusammen!

Im Rahmen eines aktuellen Projektes benötigte ich einen Parser für Kommandozeilen Argumente.
Davon gibt es ja so einige, jedoch konnte ich keinen finden der alle meine Anforderungen erfüllen konnte:
*Unterstützung für .NET Core *Parsen von bekannten Argumenten in definierte Properties *Parsen von unbekannten Argumenten als ein 'dynamic' Objekt (welches keine Exception wirft beim Zugriff von nicht definierten Properties) *Parsen von nicht gültigen Optionen in eine 'Mülleimer' Property

Deswegen habe ich das Ganze einfach mal als Übung genommen, um mein erstes Projekt für .NET Core umzusetzen. Zudem dachte ich, dass es vielleicht dem ein oder anderem auch hilft und wollte es einfach mal hier reinstellen 😃

Zufinden ist das Projekt bei Github. Die Testabdeckung sollte recht gut sein, da ich es Test-Driven entwickelt habe (Leider habe ich bisher kein Tool für Testabdeckung für .NET Core Projekte gefunden - nur für das "alte" .json Projektformat).

Muss noch das ein oder andere im Code dokumentieren und überarbeiten, aber das meiste ist getan.

Die README sollte die kleine Bibliothek recht gut erklären. Und verdeutlichen was ich mit dem ein oder anderem Punkt oben meinte 😃

Beste Grüße
Geaz

16.807 Beiträge seit 2008
vor 7 Jahren

Hat Microsoft schon etwas länger umgesetzt Microsoft.Extensions.CommandLineUtils und wird für .NET Core Templates verwendet.

NUnit und XUnit überstützen beide bereits .NET Core mit csproj.

Ansonsten sei noch gesagt, dass mich Dein Code und Deine Options sehr an https://github.com/gsscoder/commandline erinnern, das sehr bekannt ist.
Wirkt so, als ob Du Dich hier etwas mehr als nur inspirieren lassen hast... 😉

Geaz Themenstarter:in
148 Beiträge seit 2013
vor 7 Jahren

Hat Microsoft schon etwas länger umgesetzt
>
und wird für .NET Core Templates verwendet.

Super, danke! Das kannte ich tatsächlich nicht. Auf die schnelle habe ich jetzt nur das hier gefunden: https://msdn.microsoft.com/de-de/magazine/mt763239.aspx

Hast du dazu zufällig noch mehr Doku? Wäre interessant, ob sich meine Punkte damit umsetzen lassen. Wenn ja, dann war es wenigstens eine gute Übung 😃

[EDIT] Sieht mir beim Überfliegen nicht so aus, als könnte ich damit das 'dynamic' umsetzen...

NUnit und XUnit überstützen beide bereits .NET Core mit csproj.

Inklusive Code Coverage (um die es mir geht)? Dazu hatte ich bei beiden nichts gefunden. Es ging mal mit OpenCover, aber wohl nicht mehr seit der Umstellung auf .csproj.

Ansonsten sei noch gesagt, dass mich Dein Code und Deine Options sehr an
>
erinnern, das sehr bekannt ist.
Wirkt so, als ob Du Dich hier etwas mehr als nur inspirieren lassen hast... 😉

Das Options Attribut habe ich von den Parametern her vom CommandLineParser abgeschaut, da ich den sonst nutze. Er jedoch halt nicht die anderen Punkte die ich benötige unterstützt. Aber mein Code erinnert dich daran? Das wäre echt ein Zufall, weil ich mir deren Code genau null mal angeschaut habe 😄

Beste Grüße

16.807 Beiträge seit 2008
vor 7 Jahren

Code Coverage wird nicht von Test-Frameworks errechnet, sondern von der Suite drum herum - in Deinem Fall zB. Visual Studio.

dynamic macht für mich hier kein Sinn.
Parameter, die ich intern verarbeiten will, hab ich doch in den Options. Ich sprech doch keine Parameter an, die ich nicht vorher festlege 🤔
Ist auch ein untypisches verhalten, denn eine CLI sollte einen Fehler werfen, wenn ein Parameter nicht existiert.

Geaz Themenstarter:in
148 Beiträge seit 2013
vor 7 Jahren

Code Coverage wird nicht von Test-Frameworks errechnet, sondern von der Suite drum herum - in Deinem Fall zB. Visual Studio.

Das ist korrekt, deswegen habe ich mich ein wenig über deine Vorschläge gewundert. Weil ich sprach von Code Coverage und du gibts mir dann zwei Testframeworks 😃

dynamic macht für mich hier kein Sinn.
Parameter, die ich intern verarbeiten will, hab ich doch in den Options. Ich sprech doch keine Parameter an, die ich nicht vorher festlege 👶
Ist auch ein untypisches verhalten, denn eine CLI sollte einen Fehler werfen, wenn ein Parameter nicht existiert.

In "normalen" Fällen ist das korrekt. Aber wie erwähnt, war es nunmal eine Anforderung für eins meiner Projekte (warum es dort Sinn macht kann ich dir gerne per PM schreiben, da es hier den Rahmen sprengen würde). Und genau für diese Anforderung habe ich halt keine Bibliothek gefunden, weshalb diese hier entstand.

Grüße

16.807 Beiträge seit 2008
vor 7 Jahren

Da hab ich Deine Aussage bzgl. der Tests gestern Abend wohl falsch verstanden.

.NET Core ist in Sachen Tools noch instabil.
Ich würde da nicht zu viel Zeit verschwenden alles an Tools zu suchen, was man noch aus der alten .NET Framework-Welt gewohnt ist.
Soweit ist das .NET Core Ökosystem noch nicht. Mit VS 2017 kommen aber viele geniale Sachen, wie Live Unit Testing etc.