Publier une démo à durée limitée de votre app .NET

Toutes les builds ne sont pas faites pour durer. Une démo de conférence devrait cesser de fonctionner la semaine après l’exposé. Une copie d’évaluation remise à un prospect ne devrait pas encore tourner en production un an plus tard. Une bêta limitée dans le temps a besoin d’une coupure nette pour que les testeurs mettent à jour au lieu de livrer discrètement la préversion. Pour tous ces cas, vous ne voulez pas d’un serveur de licences ni de comptes — vous voulez que la build elle-même expire. Nebula.NET peut compiler cette expiration directement dans l’assembly.

Un seul réglage

Vous ajoutez une expiration comme vous configurez n’importe quelle autre protection — dans la config Nebula :

{
  "rename": true,
  "controlFlowObfuscation": true,
  "expiryUtc": "2026-12-31T23:59:59Z",
  "expiryReaction": "exit",
  "expiryMessage": "This evaluation build expired on 2026-12-31. Contact sales for a licensed copy."
}

C’est toute la surface de la fonctionnalité : un instant UTC, une réaction et un message facultatif. Nebula injecte l’application pendant l’obfuscation — il n’y a rien à ajouter à votre source, pas de using, pas d’appel d’API, et donc rien qu’un lecteur de votre code décompilé puisse trouver et retirer par son nom.

Où s’exécute la vérification — avant votre code

La décision de conception importante est l’endroit où vit la vérification de date. Nebula l’injecte dans l’initialiseur de module — le .cctor au niveau du module que le CLR exécute exactement une fois, automatiquement, avant que le moindre type du module ne soit touché. Il s’exécute avant Main, avant tout constructeur statique à vous, avant tout point d’entrée :

// injecté dans <Module>::.cctor, conceptuellement :
ldc.i8     <expiryTicks>                 // 2026-12-31T23:59:59Z en ticks UTC
call       valuetype [System.Runtime]System.DateTime [System.Runtime]System.DateTime::get_UtcNow()
call       instance int64 [System.Runtime]System.DateTime::get_Ticks()
bgt.s      EXPIRED                        // now > expiry → réagit
// ... poursuit l'initialisation normale du module
EXPIRED:
// la réaction configurée (exit / throw / callback)

Comme c’est un initialiseur de module, aucun chemin d’exécution vers votre assembly ne le saute. Comparez avec le fait de semer des if (DateTime.UtcNow > …) dans vos propres méthodes : vous devriez vous souvenir de chaque point d’entrée, et chaque vérification est une branche lisible dans votre source. Le garde injecté est unique, automatique et ajouté au niveau IL une fois votre compilateur terminé.

Choisir la réaction

L’application est le travail de Nebula ; ce qui se produit à l’expiration est à vous de choisir avec expiryReaction :

• exit (par défaut) — le processus se termine immédiatement. Le plus simple et le plus difficile à contourner par la parole ; idéal pour une démo pure.
• throw — une exception est levée que vous pouvez attraper à votre niveau supérieur et transformer en un écran convivial, un événement journalisé ou un arrêt ordonné.
• callback — Nebula invoque une méthode que vous désignez, vous gardez donc le contrôle total : afficher une boîte de dialogue WPF, basculer l’app en mode lecture seule, ou signaler qu’une démo a expiré.

Une réaction callback pointe vers l’une de vos méthodes par son nom :

{
  "expiryUtc": "2026-12-31T23:59:59Z",
  "expiryReaction": "callback",
  "expiryCallback": "MyApp.Startup.OnEvaluationExpired"
}

namespace MyApp;
static class Startup
{
    // Appelée par le garde injecté quand la build dépasse sa date.
    public static void OnEvaluationExpired()
    {
        MessageBox.Show("Your evaluation of MyApp has ended. Visit example.com to license it.");
        Environment.Exit(0);
    }
}

Le garde appelle votre méthode ; vous décidez de l’expérience. Si la méthode retourne, vous contrôlez ce qui se passe ensuite — il n’y a pas de second comportement caché.

Elle s’associe au reste de la protection

Une expiration seule n’est masquée qu’autant que le code qui l’entoure, c’est pourquoi c’est une transformation dans le même pipeline que tout le reste. Exécutez-la avec le renommage, l’obfuscation du flux de contrôle et — en Enterprise — le chiffrement de méthodes ou la virtualisation, et la comparaison, la constante d’expiration et la réaction sont enfouies dans la même sortie aplatie et chiffrée que le reste de votre logique, pas dans une branche DateTime évidente. Le garde est aussi une fonctionnalité sous licence (payante) : une build de l’édition Free l’abandonne silencieusement au lieu de livrer une date à moitié appliquée, de sorte qu’une démo que vous entendez faire expirer expire réellement.

Quand recourir plutôt à la licence

Soyez honnête sur ce qu’une date intégrée est et n’est pas. C’est une dissuasion pour un usage honnête — elle fait s’arrêter une démo ou une évaluation à la date prévue pour qu’elle ne fuie pas en production ni ne survive à son objet. Ce n’est pas une frontière dure contre un attaquant motivé, car toute vérification de date locale peut être attaquée en reculant l’horloge, et une build figée ne peut être ni prolongée, ni révoquée, ni convertie sans en livrer une autre.

Quand l’utilisateur a un compte et que vous voulez gérer son accès dans le temps — prolonger un essai, le convertir en payant sur place, révoquer une copie fuitée, revalider en ligne pour que l’horloge locale n’ait plus d’importance — c’est de la licence logicielle, pas de l’expiration. Les deux se composent proprement : livrez des builds d’évaluation avec une expiration nette pour le cas occasionnel, et une vraie licence pour les clients. Voyez ajouter un essai gratuit pour la voie côté serveur, et protéger vos vérifications de licence une fois que vous les avez. Mais pour une build jetable qui doit simplement s’arrêter à une date, une ligne de config fait tout le travail.