Eine zeitlich begrenzte Demo Ihrer .NET-App veröffentlichen

Nicht jeder Build ist dafür gemacht, ewig zu leben. Eine Konferenzdemo sollte die Woche nach dem Vortrag aufhören zu funktionieren. Eine Evaluierungskopie, die einem Interessenten überreicht wird, sollte ein Jahr später nicht immer noch in Produktion laufen. Eine zeitlich begrenzte Beta braucht einen harten Stichtag, damit Tester aktualisieren, statt die Vorabversion heimlich auszuliefern. Für all das wollen Sie keinen Lizenzserver und keine Konten — Sie wollen, dass der Build selbst abläuft. Nebula.NET kann dieses Ablaufdatum direkt in den Assembly kompilieren.

Eine einzige Einstellung

Sie fügen ein Ablaufdatum genauso hinzu, wie Sie jede andere Schutzmaßnahme konfigurieren — in der Nebula-Konfiguration:

{
  "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."
}

Das ist die ganze Oberfläche der Funktion: ein UTC-Zeitpunkt, eine Reaktion und eine optionale Nachricht. Nebula injiziert die Durchsetzung während der Obfuskierung — es gibt nichts zu Ihrem Quellcode hinzuzufügen, kein using, keinen API-Aufruf und damit nichts, das jemand, der Ihren dekompilierten Code liest, am Namen finden und entfernen könnte.

Wo die Prüfung läuft — vor Ihrem Code

Die wichtige Designentscheidung ist, wo die Datumsprüfung lebt. Nebula injiziert sie in den Modul-Initialisierer — den Modul-.cctor, den die CLR genau einmal, automatisch, ausführt, bevor irgendein Typ des Moduls berührt wird. Er läuft vor Main, vor jedem eigenen statischen Konstruktor, vor jedem Einstiegspunkt:

// injiziert in <Module>::.cctor, konzeptionell:
ldc.i8     <expiryTicks>                 // 2026-12-31T23:59:59Z als UTC-Ticks
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 → reagiert
// ... normale Modul-Initialisierung fortsetzen
EXPIRED:
// die konfigurierte Reaktion (exit / throw / callback)

Da es ein Modul-Initialisierer ist, gibt es keinen Ausführungspfad in Ihren Assembly, der ihn überspringt. Vergleichen Sie das mit dem Verteilen von if (DateTime.UtcNow > …) über Ihre eigenen Methoden: Sie müssten sich an jeden Einstiegspunkt erinnern, und jede Prüfung ist ein lesbarer Zweig in Ihrem Quellcode. Der injizierte Wächter ist singulär, automatisch und auf IL-Ebene hinzugefügt, nachdem Ihr Compiler fertig ist.

Die Reaktion wählen

Die Durchsetzung ist Nebulas Aufgabe; was beim Ablauf geschieht, wählen Sie mit expiryReaction:

• exit (Standard) — der Prozess wird sofort beendet. Am einfachsten und am schwersten wegzureden; gut für eine reine Demo.
• throw — eine Ausnahme wird ausgelöst, die Sie auf oberster Ebene abfangen und in einen freundlichen Bildschirm, ein protokolliertes Ereignis oder ein geordnetes Herunterfahren verwandeln können.
• callback — Nebula ruft eine von Ihnen benannte Methode auf, Sie behalten also die volle Kontrolle: einen WPF-Dialog zeigen, die App in einen Nur-Lese-Modus schalten oder nach Hause melden, dass eine Demo abgelaufen ist.

Eine Callback-Reaktion zeigt per Name auf eine Ihrer eigenen Methoden:

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

namespace MyApp;
static class Startup
{
    // Vom injizierten Wächter aufgerufen, wenn der Build sein Datum überschreitet.
    public static void OnEvaluationExpired()
    {
        MessageBox.Show("Your evaluation of MyApp has ended. Visit example.com to license it.");
        Environment.Exit(0);
    }
}

Der Wächter ruft Ihre Methode auf; Sie entscheiden über das Erlebnis. Kehrt die Methode zurück, steuern Sie, was als Nächstes passiert — es gibt kein verborgenes zweites Verhalten.

Es greift mit dem Rest des Schutzes ineinander

Ein Ablaufdatum allein ist nur so verborgen wie der Code darum herum, weshalb es eine Transformation in derselben Pipeline wie alles andere ist. Führen Sie es zusammen mit Umbenennung, Kontrollfluss-Obfuskierung und — in Enterprise — Methodenverschlüsselung oder Virtualisierung aus, und der Vergleich, die Ablaufkonstante und die Reaktion sind in derselben verflachten, verschlüsselten Ausgabe vergraben wie der Rest Ihrer Logik, nicht in einem offensichtlichen DateTime-Zweig. Der Wächter ist außerdem eine lizenzierte (kostenpflichtige) Funktion: ein Build der Free-Edition lässt ihn stillschweigend weg, statt ein halb durchgesetztes Datum auszuliefern, sodass eine Demo, die ablaufen soll, tatsächlich abläuft.

Wann Sie stattdessen zur Lizenzierung greifen

Seien Sie ehrlich, was ein eingebackenes Datum ist und nicht ist. Es ist eine Abschreckung für ehrliche Nutzung — es lässt eine Demo oder Evaluierung planmäßig anhalten, damit sie nicht in die Produktion sickert oder ihren Zweck überdauert. Es ist keine harte Grenze gegen einen motivierten Angreifer, denn jede lokale Datumsprüfung lässt sich durch Zurückdrehen der Uhr angreifen, und ein fester Build lässt sich nicht verlängern, widerrufen oder umwandeln, ohne einen neuen auszuliefern.

Wenn der Nutzer ein Konto hat und Sie seinen Zugang über die Zeit verwalten wollen — einen Testzeitraum verlängern, ihn an Ort und Stelle in bezahlt umwandeln, eine durchgesickerte Kopie widerrufen, online revalidieren, damit die lokale Uhr keine Rolle spielt — dann ist das Software-Lizenzierung, kein Ablaufdatum. Beide lassen sich sauber kombinieren: liefern Sie Evaluierungs-Builds mit einem harten Ablaufdatum für den Gelegenheitsfall und eine echte Lizenz für Kunden. Siehe einen kostenlosen Testzeitraum hinzufügen für den serverbasierten Weg und Ihre Lizenzprüfungen schützen, sobald Sie sie haben. Für einen Wegwerf-Build jedoch, der einfach an einem Datum anhalten soll, ist eine Zeile Konfiguration die ganze Arbeit.