Outil Babel Licensing ★Server

Contenu du package

Babel.Licensing.Tool est un package d’outil .NET  qui installe la commande lic. Il s’agit du même outil en ligne de commande que celui des archives zip de Babel, avec les mêmes options, et il est fourni avec les éditions de Babel Licensing, Server et Data Center. Le package contient un build de l’outil pour chaque runtime pris en charge, de .NET 6.0 à .NET 10.0, et le CLI dotnet choisit le build qui correspond au SDK de la machine.

Comme les autres packages Babel, le package de l’outil n’est pas publié sur nuget.org : hébergez-le sur votre propre flux comme décrit dans Héberger le package, ou ajoutez-le à un flux de dossier local comme indiqué dans Composants client.

Quand utiliser l’outil

Utilisez l’outil partout où les licences sont produites par un processus plutôt que par une personne dans Babel Desktop :

• Émettre des licences depuis un pipeline de traitement des commandes, un script d’assistance ou un build, sur tout système d’exploitation.
• Générer et renouveler des paires de clés de signature, et exporter la clé publique à incorporer dans une application.
• Vérifier les licences que les clients vous renvoient, et les mettre à jour sans les recréer.
• Calculer la clé matérielle d’une machine, pour émettre une licence liée à cette machine.
• Automatiser avec des agents grâce au mode adapté à l’IA, que l’outil lic partage avec l’obfuscateur.

Installer l’outil

Outil global

Un outil global s’installe une fois par utilisateur et est disponible depuis tous les terminaux :

dotnet tool install Babel.Licensing.Tool -g

Si le flux ne figure pas dans un fichier NuGet.config, indiquez-le explicitement. La source peut être l’URL d’un flux ou un dossier local :

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

Sous Linux et macOS, vérifiez que le dossier des outils figure dans le chemin de recherche, sinon la commande lic est introuvable :

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

Outil local

Un outil local est épinglé à un dépôt au moyen d’un manifeste d’outils, de sorte que chaque développeur et chaque agent de CI exécutent la même version :

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

L’outil est ainsi inscrit dans .config/dotnet-tools.json, fichier que vous validez dans le dépôt. Sur toute autre machine, dotnet tool restore installe la version épinglée. Un outil local s’appelle par l’intermédiaire du CLI dotnet :

dotnet lic --version

Mettre à jour et désinstaller

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

Omettez -g pour un outil local. dotnet tool list affiche le package installé, sa version et la commande lic qu’il fournit, à côté de babel lorsque l’outil de l’obfuscateur est lui aussi installé. Les mêmes commandes sont décrites dans Installation.

Fournir la licence à l’outil

L’outil a besoin d’une licence Babel Licensing. Un outil dotnet n’a pas de dossier d’installation où copier babel.licenses : fournissez donc la licence à lic de l’une des façons suivantes :

• Réglez la variable d’environnement BABEL_LICENSE_PATH sur le chemin complet du fichier de licence. C’est la configuration recommandée sur les machines de développement et les agents de build :

export BABEL_LICENSE_PATH=~/Babel/babel.licenses

• Passez --license à chaque appel, avec le chemin du fichier de licence ou d’un dossier où le rechercher.
• Passez --license env:BABEL_LICENSE, où la variable contient une clé de licence : c’est le bon choix sur les serveurs de build, où la clé est conservée dans un secret.

lic --license sans argument affiche la licence utilisée. Un fichier de licence est valable pour une seule version du produit : utilisez le fichier fourni avec la même version que l’outil, et mettez les deux à jour ensemble.

Utiliser l’outil

La commande lic accepte la syntaxe et les options décrites dans Outils en ligne de commande et dans la Référence. Un appel type indique l’assembly à mettre sous licence, la clé, le contenu de la licence et le fichier de sortie :

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

Avec un outil local, faites précéder la commande de dotnet.

Scripts et automatisation

Depuis la version 11.8, la ligne de commande lic dispose d’un mode adapté à l’IA conçu pour les scripts et les agents :

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

--format json ou ndjson transforme la sortie en flux lisible par machine et dirige les diagnostics destinés aux personnes vers la sortie d’erreur standard, --quiet supprime la bannière et fait échouer immédiatement toute invite interactive, et --strict-exit renvoie un code de sortie distinct pour les arguments non valides, l’entrée manquante, les échecs de traitement de la licence, les échecs liés à la licence de l’outil et les échecs de signature. Les codes de sortie sont les mêmes que ceux de l’obfuscateur : un seul script peut donc piloter les deux outils avec un tableau unique.

Exécuter l’outil sur un serveur de build

L’outil convient aux pipelines dont une étape émet des licences, par exemple pour mettre sous licence le build de test d’une application avant l’exécution de ses tests d’intégration. Avec un manifeste d’outils validé dans le dépôt et le flux configuré dans NuGet.config (voir l’exemple GitHub Actions pour une configuration qui s’authentifie auprès de GitHub Packages), un travail (job) GitHub Actions se présente ainsi :

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 }}

Conservez la clé privée dans un secret et jamais dans le dépôt : quiconque la détient peut émettre des licences pour votre produit.

Dépannage

• lic: command not found : le dossier des outils globaux ne figure pas dans le chemin de recherche ; ajoutez ~/.dotnet/tools à PATH, ou utilisez un outil local et exécutez dotnet lic.
• Un message demandant d’installer .NET : le build sélectionné de l’outil nécessite le runtime .NET correspondant, de 6.0 à 10.0. Installez ce runtime, ou définissez DOTNET_ROLL_FORWARD=Major pour exécuter l’outil sur un runtime plus récent.
• A valid license could not be found : vérifiez BABEL_LICENSE_PATH ou l’argument --license, puis exécutez lic --license pour voir ce que l’outil a chargé. Un fichier de licence prévu pour une autre version est signalé comme non valide.
• L’application signale que la licence n’est pas valide : la licence a probablement été écrite sans --sign, ou signée avec une paire de clés dont la clé publique ne correspond pas à celle qui est incorporée dans l’application. Exécutez lic <file> --verify --keyfile <key> pour vérifier la signature avec la clé attendue.
• Unrecognized option : c’est un lic plus ancien, présent dans le chemin de recherche, qui répond ; exécutez dotnet tool list -g et lic --version pour vérifier quel build vous appelez. --format json, --quiet et --strict-exit nécessitent la version 11.8 ou une version ultérieure.