Skip to Content
Neue Version 12 verfügbar 🎉
LicensingBefehlszeileBabel Licensing Tool

Babel Licensing Tool Server

Babel.Licensing.Tool stellt die Befehlszeile lic als dotnet-Tool bereit. So erzeugen und verwalten Sie Lizenzen aus einem Terminal oder einem Skript unter Windows, Linux und macOS, und brauchen dafür nur das installierte .NET SDK.

Inhalt des Pakets

Babel.Licensing.Tool ist ein Paket vom Typ .NET-Tool , das den Befehl lic installiert. Es ist dasselbe Befehlszeilentool, das in den Zip-Paketen von Babel ausgeliefert wird, mit denselben Optionen, und es gehört zu den Editionen von Babel Licensing, Server und Data Center. Das Paket enthält je einen Build des Tools für jede unterstützte Laufzeit, von .NET 6.0 bis .NET 10.0, und die dotnet CLI wählt den Build, der zum SDK auf dem Rechner passt.

Wie die anderen Babel-Pakete liegt das Tool-Paket nicht auf nuget.org: Hosten Sie es in Ihrem eigenen Feed, wie unter Das Paket hosten beschrieben, oder legen Sie es in einem lokalen Ordner-Feed ab, wie unter Client-Komponenten gezeigt.

Wann Sie das Tool verwenden

Verwenden Sie das Tool überall dort, wo Lizenzen von einem Prozess und nicht von einer Person in Babel Desktop erzeugt werden:

  • Lizenzen aus einer Bestellpipeline, einem Supportskript oder einem Build ausstellen, unter jedem Betriebssystem.
  • Signaturschlüsselpaare erzeugen und rotieren und den öffentlichen Schlüssel exportieren, um ihn in eine Anwendung einzubetten.
  • Lizenzen prüfen, die Kunden zurücksenden, und sie aktualisieren, ohne sie neu zu erstellen.
  • Den Hardwareschlüssel eines Rechners berechnen, um eine hardwaregebundene Lizenz für ihn auszustellen.
  • Automatisierung durch Agenten über den KI-freundlichen Modus, den das Tool lic mit dem Obfuscator teilt.

Das Tool erzeugt Lizenzen, die die Anwendung offline mit der Clientbibliothek Babel.Licensing validiert. Lizenzen, die der Babel Licensing Service verwaltet, etwa Aktivierungs- und Floating-Lizenzen, werden stattdessen mit den Tools des Dienstes erstellt: Babel Desktop, die Webanwendung (Data Center), die REST-API oder der MCP-Server.

Das Tool installieren

Globales Tool

Ein globales Tool wird einmal je Benutzer installiert und steht in jedem Terminal zur Verfügung:

dotnet tool install Babel.Licensing.Tool -g

Wenn der Feed in keiner Datei NuGet.config aufgeführt ist, geben Sie ihn ausdrücklich an. Die Quelle kann die URL eines Feeds oder ein lokaler Ordner sein:

dotnet tool install Babel.Licensing.Tool -g --add-source ~/NuGet

Achten Sie unter Linux und macOS darauf, dass der Tools-Ordner im Pfad liegt, sonst wird der Befehl lic nicht gefunden:

export PATH="$PATH:$HOME/.dotnet/tools"

Lokales Tool

Ein lokales Tool wird über ein Toolmanifest an ein Repository gebunden, sodass jeder Entwickler und jeder CI-Agent dieselbe Version ausführt:

dotnet new tool-manifest dotnet tool install Babel.Licensing.Tool

Dadurch wird das Tool in .config/dotnet-tools.json eingetragen, einer Datei, die Sie einchecken. Auf jedem anderen Rechner installiert dotnet tool restore die festgelegte Version. Ein lokales Tool wird über die dotnet CLI aufgerufen:

dotnet lic --version

Aktualisieren und entfernen

dotnet tool update Babel.Licensing.Tool -g dotnet tool list -g dotnet tool uninstall Babel.Licensing.Tool -g

Lassen Sie -g bei einem lokalen Tool weg. dotnet tool list zeigt das installierte Paket, seine Version und den Befehl lic, den es bereitstellt, neben babel, wenn auch das Tool des Obfuscators installiert ist. Dieselben Befehle sind unter Installation beschrieben.

Das Tool lizenzieren

Das Tool braucht eine Lizenz für Babel Licensing. Ein dotnet-Tool hat keinen Installationsordner, in den Sie babel.licenses kopieren könnten. Übergeben Sie lic die Lizenz daher auf einem dieser Wege:

  • Setzen Sie die Umgebungsvariable BABEL_LICENSE_PATH auf den vollständigen Pfad der Lizenzdatei. Das ist die empfohlene Einrichtung auf Entwicklerrechnern und Buildagents:
export BABEL_LICENSE_PATH=~/Babel/babel.licenses
  • Übergeben Sie bei jedem Aufruf --license mit dem Pfad der Lizenzdatei oder eines Ordners, der durchsucht werden soll.
  • Übergeben Sie --license env:BABEL_LICENSE, wobei die Variable einen Lizenzschlüssel enthält: die richtige Wahl auf Buildservern, wo der Schlüssel als Geheimnis hinterlegt ist.

lic --license ohne Argument gibt die verwendete Lizenz aus. Eine Lizenzdatei gilt für eine Produktversion: Verwenden Sie die Datei, die mit derselben Version wie das Tool geliefert wurde, und aktualisieren Sie beide zusammen.

Das Tool verwenden

Der Befehl lic akzeptiert die Syntax und die Schalter, die unter Befehlszeilentools und in der Referenz beschrieben sind. Ein typischer Aufruf nennt die zu lizenzierende Assembly, den Schlüssel, den Inhalt der Lizenz und die Ausgabedatei:

lic MyApp.dll --keyfile keys.pem --sign --licensee name="Contoso" --product name="MyApp" --expiredate 365 --feature Pro=1 --trial days=30 --output MyApp.licenses --encoding utf-8

Stellen Sie dem Befehl bei einem lokalen Tool dotnet voran.

Skripte und Automatisierung

Seit Version 11.8 hat die Befehlszeile lic einen KI-freundlichen Modus, der für Skripte und Agenten gedacht ist:

lic MyApp.dll --keyfile keys.pem --sign --licensee name="Contoso" --expiredate 365 --format json --quiet --strict-exit

--format json oder ndjson macht aus der Ausgabe einen maschinenlesbaren Datenstrom und leitet die für Menschen bestimmten Diagnosemeldungen auf die Standardfehlerausgabe. --quiet entfernt das Banner und lässt jede interaktive Eingabeaufforderung sofort fehlschlagen. --strict-exit gibt für ungültige Argumente, fehlende Eingaben sowie Fehler bei der Lizenzverarbeitung, der Lizenzierung und der Signierung je einen eigenen Exitcode zurück. Die Exitcodes sind dieselben wie beim Obfuscator, sodass ein Skript beide Tools mit einer einzigen Tabelle steuern kann.

Ausführung auf einem Buildserver

Das Tool passt in Pipelines, die Lizenzen in einem eigenen Schritt ausstellen, zum Beispiel um den Testbuild einer Anwendung zu lizenzieren, bevor ihre Integrationstests laufen. Mit einem ins Repository eingecheckten Toolmanifest und dem in NuGet.config konfigurierten Feed (das Beispiel GitHub Actions zeigt eine Konfiguration, die sich bei GitHub Packages authentifiziert) sieht ein Auftrag in GitHub Actions so aus:

steps: - uses: actions/checkout@v4 - uses: actions/setup-dotnet@v4 with: dotnet-version: '10.0.x' - name: Restore tools run: dotnet tool restore env: PACKAGES_TOKEN: ${{ secrets.PACKAGES_TOKEN }} - name: Write the signing key run: echo "$SIGNING_KEY" > keys.pem env: SIGNING_KEY: ${{ secrets.LICENSE_SIGNING_KEY }} - name: Issue the test license run: dotnet lic artifacts/MyApp.dll --license env:BABEL_LICENSE --keyfile keys.pem --sign --licensee name="CI" --expiredate 7 --output artifacts/MyApp.licenses --quiet --strict-exit env: BABEL_LICENSE: ${{ secrets.BABEL_LICENSE_SECRET }}

Bewahren Sie den privaten Schlüssel als Geheimnis auf und nie im Repository: Wer ihn besitzt, kann Lizenzen für Ihr Produkt ausstellen.

Fehlerbehebung

  • lic: command not found: Der Ordner der globalen Tools liegt nicht im Pfad. Nehmen Sie ~/.dotnet/tools in PATH auf, oder verwenden Sie ein lokales Tool und führen Sie dotnet lic aus.
  • Eine Meldung, die zur Installation von .NET auffordert: Der gewählte Build des Tools braucht die passende .NET-Laufzeit, von 6.0 bis 10.0. Installieren Sie diese Laufzeit, oder setzen Sie DOTNET_ROLL_FORWARD=Major, um das Tool auf einer neueren Laufzeit auszuführen.
  • A valid license could not be found: Prüfen Sie BABEL_LICENSE_PATH oder das Argument von --license, und führen Sie dann lic --license aus, um zu sehen, was das Tool geladen hat. Eine Lizenzdatei für eine andere Version wird als ungültig gemeldet.
  • Die Anwendung meldet die Lizenz als ungültig: Die Lizenz wurde wahrscheinlich ohne --sign geschrieben oder mit einem Schlüsselpaar signiert, dessen öffentlicher Schlüssel nicht mit dem in die Anwendung eingebetteten übereinstimmt. Führen Sie lic <file> --verify --keyfile <key> aus, um die Signatur mit dem erwarteten Schlüssel zu prüfen.
  • Unrecognized option: Es antwortet ein älteres lic aus dem Pfad. Führen Sie dotnet tool list -g und lic --version aus, um zu prüfen, welchen Build Sie aufrufen. --format json, --quiet und --strict-exit setzen Version 11.8 oder höher voraus.
Last updated on