# Launch-Anwendungsintegrationspakete

Launch **0.1.6** enthält das offizielle Licentivo SDK **0.11.6** für alle **neun Sprachen**. Installieren Sie nur das Launch-Paket für Ihre Sprache. Implementierung, Standardadapter, Lizenzhinweise und SDK-Linkkonfiguration sind enthalten. TypeScript-Deklarationen gehören zu JavaScript; das vertrauenswürdige Go-Web-Backend ist ein zusätzliches Beispiel. Öffentliche Quellen, Registry-Befehle und Verfügbarkeit je Sprache werden im [Launch SDK-Repository](https://github.com/spf86/licentivo-launch-sdk) und dessen [Veröffentlichungsstatus](https://github.com/spf86/licentivo-launch-sdk/blob/main/docs/registry-status.json) gepflegt.

Das Update 0.1.6 enthält die vorgelagerte C/C++-CMake-Korrektur für curl-config-package- und FindCURL-Nutzer. Lizenzierungsprotokoll, Anwendungs-APIs und Kontolebenszyklus sind unverändert. Bestehende Anwendungen können das Launch-Paket aktualisieren und ohne Änderung ihres Integrationscodes neu bauen. Der [Veröffentlichungsnachweis für 0.1.6](https://github.com/spf86/licentivo-launch-sdk/blob/main/docs/publication-0.1.6.md) dokumentiert öffentliche Verfügbarkeit und Prüfung sauberer Installationen getrennt von lokalen Builds.

| Sprache | Einzelnes Launch-Artefakt | Paketquelle / API-Anleitung |
| --- | --- | --- |
| Go | Eigenständiges Modul-ZIP | [pkg/launchclient](https://github.com/spf86/licentivo-launch/blob/main/pkg/launchclient/README.md) |
| Python | licentivo_launch-0.1.6-py3-none-any.whl | [sdk/python](https://github.com/spf86/licentivo-launch/blob/main/sdk/python/README.md) |
| C# / .NET 8 | Licentivo.Launch.0.1.6.nupkg | [sdk/csharp](https://github.com/spf86/licentivo-launch/blob/main/sdk/csharp/README.md) |
| Java 17 | launch-client-0.1.6.jar und POM | [sdk/java](https://github.com/spf86/licentivo-launch/blob/main/sdk/java/README.md) |
| JavaScript / Node.js | licentivo-launch-0.1.6.tgz | [sdk/javascript](https://github.com/spf86/licentivo-launch/blob/main/sdk/javascript/README.md) |
| Rust | licentivo-launch-0.1.6.crate oder Quellcode-ZIP | [sdk/rust](https://github.com/spf86/licentivo-launch/blob/main/sdk/rust/README.md) |
| Ruby | Plattformspezifisches Launch-Gem oder Quellcode-Gem | [sdk/ruby](https://github.com/spf86/licentivo-launch/blob/main/sdk/ruby/README.md) |
| C | Natives Launch-CMake-Installations-ZIP | [sdk/native](https://github.com/spf86/licentivo-launch/blob/main/sdk/native/README.md) |
| C++ | Dasselbe native Archiv, C++17 API | [sdk/native](https://github.com/spf86/licentivo-launch/blob/main/sdk/native/README.md) |

## Aus einer öffentlichen Registry installieren

Öffentliche Installationsprüfungen für 0.1.6 waren für alle neun Sprachen erfolgreich: Go, Python, C#, Java, Node.js/TypeScript, Rust, Ruby, C und C++. Die folgenden Registry-Befehle und nativen Downloads sind öffentlich verfügbar und in unabhängigen Verbraucherprojekten geprüft. Der Veröffentlichungsstatus enthält genaue Paketprüfsummen, Installationsergebnisse und Plattformgrenzen.

```sh
go get github.com/spf86/licentivo-launch-sdk/pkg/launchclient@v0.1.6
python -m pip install licentivo-launch==0.1.6
npm install @licentivo/launch@0.1.6
dotnet add package Licentivo.Launch --version 0.1.6
cargo add licentivo-launch@=0.1.6
gem install licentivo-launch --version 0.1.6
```

Java verwendet Maven-/Gradle-Koordinaten `com.licentivo.launch:launch-client:0.1.6`.
C/C++ verwenden das ABI-kompatible native Archiv aus dem [versionierten GitHub-Release](https://github.com/spf86/licentivo-launch-sdk/releases/tag/v0.1.6).
Siehe Veröffentlichungsstatus für Registry-Verbreitung und Verifikationsergebnisse.

## Eine heruntergeladene Distribution installieren

Die in integration-packages.json angegebenen Artefakte verwenden. Für jede Sprache sind sdk_managed: true und requires_separate_official_sdk: false verzeichnet. SHA256SUMS vor der Installation prüfen.

```powershell
python -m pip install ./licentivo_launch-0.1.6-py3-none-any.whl
npm install ./licentivo-launch-0.1.6.tgz
dotnet add YOUR_PROJECT package Licentivo.Launch --version 0.1.6 --source YOUR_LOCAL_FEED
gem install --local ./licentivo-launch-0.1.6-x64-mingw-ucrt.gem
```

Java verwendet nur die Launch-JAR im Klassenpfad; ihre POM hat keine Abhängigkeit vom offiziellen SDK. Offline-Go-Nutzer können das Modul-ZIP entpacken und ein lokales require/replace für `github.com/spf86/licentivo-launch-sdk` verwenden. Offline-Rust-Nutzer können das Crate oder Quellcode-ZIP entpacken und eine lokale licentivo-launch-Pfadabhängigkeit hinzufügen. Ein offizielles SDK-Paket oder Checkout ist nicht erforderlich.

Für C/C++ das native Installations-ZIP entpacken, sein Präfix zu CMake hinzufügen und Folgendes verwenden:

```cmake
find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)
# C++17 target: licentivo_launch_link(myapp CXX)
```

Launch löst sein eigenes SDK, transitive Bibliotheken und gebündelte Windows-DLLs auf. Rusts build.rs kompiliert seinen eingebetteten C-Kern und kopiert gebündelte DLLs neben Cargo-Programme. Rubys Plattform-Gem enthält seinen privaten nativen Kern und Laufzeitbibliotheken; das Quellcode-Gem kompiliert den Kern automatisch.

Normale Sprach-Toolchains und gewöhnliche Abhängigkeiten gelten weiterhin: pip löst cryptography auf, NuGet löst BouncyCastle.Cryptography auf und Cargo löst gewöhnliche Rust-Crates auf. Native Archive decken Windows amd64 GNU und Linux amd64 ab. Windows-Distributionen enthalten curl. Andere Betriebssysteme verwenden den vollständigen Quellcode mit einem C11-Compiler und normalen OS-curl/OpenSSL-Entwicklungsbibliotheken. Der native Windows-Kern von SDK 0.11.6 erfordert GNU/MinGW.

## Anwendung initialisieren

Die vorhandene Software in Launch auswählen. Launch liest automatisch die aktuelle Händler-URL, die bestehende Plan-/Produktzuordnung und die offiziellen öffentlichen Signaturschlüssel und stellt eine ausgefüllte Verbindungsfunktion bereit. Diese Funktion in die Anwendung kopieren; weder manuelle Eingabe interner IDs noch Erstellung einer Konfigurationsdatei ist erforderlich. Der Serverstart verwendet weiterhin die private config.yaml, die niemals mit der Anwendung ausgeliefert wird.

Den Paketeinstieg verwenden, beispielsweise launchclient.Connect, Python Application.connect, C# Application.Connect oder Node Application.connect. Die integrierte Factory erstellt und verwaltet das SDK. Benutzerdefinierte Factories sind optionale Test-/Integrations-Hooks, keine Installationsschritte. Die genauen APIs stehen in README und Beispiel jedes Pakets.

Launch behandelt Kontoanmeldung, bereichsgebundene Zugangsdaten, begrenzte Wiederholungen ausstehender Vorgänge und Wiederherstellung. Das eingebettete SDK prüft Signaturen und autorisiert jede geschützte Operation. Normales Schließen, Logout und Gerätefreigabe bleiben getrennt. Webanwendungen prüfen Berechtigungen auf einem vertrauenswürdigen Backend; Node-/Electron-Code gehört in den Haupt- oder Serverprozess.

Manuelle Entwicklungsanweisungen stehen weiterhin in [manual-integration.md](/de/launch-documents/manual-integration/) und der README jeder Sprache. Die KI-Integrationsseite der Administration erzeugt englische Anweisungen für denselben direkten Initialisierungsablauf. Sie schließt Passwörter, Management-Schlüssel und Laufzeit-Kunden-/Gerätezugangsdaten aus und ruft keinen KI-Dienst auf. Siehe [KI-Integration](/de/launch-documents/ai-integration/).

## Distributionen als Maintainer erstellen

Nur Maintainer, die das eingebettete SDK aktualisieren, benötigen geprüfte Upstream-Quellen. Nutzer überspringen diesen Abschnitt.

```powershell
./scripts/prepare-examples.ps1 -Source 'C:\path\to\reviewed-sdk\sdk'
./scripts/build-integration-packages.ps1 -Output artifacts/NEW_DIRECTORY -BuildRustCrate -BuildNative -CurlRoot PATH_TO_CURL -CCompiler PATH_TO_GCC
```

Toolpfade bei Bedarf mit -Python, -DotNet, -JavaHome, -Ruby, -Cargo und -CMake angeben. Der Builder prüft das Upstream-Manifest; anschließend bettet prepare-managed-sdk.mjs die Quellen ein und erfasst Quell-/Ziel-SHA-256-Werte in sdk/managed-sdk-manifest.json. Modulorte/Imports ändern sich bei Bedarf; kryptografische Verifikation verbleibt in der geprüften Implementierung. MIT-Lizenzen und Hinweise begleiten jede eingebettete Kopie.

Jeder Build erstellt ein neues Verzeichnis mit Artefakten je Sprache, Quellarchiven, einem kombinierten Quellbundle, Inventar und Prüfsummen. -SourceOnly erzeugt ausdrücklich Quellartefakte; übersprungene Ziele sind keine getesteten Binär-Releases. Das kombinierte Bundle bewahrt Paket-, Beispiel-, Dokumentations- und Testpfade ohne examples/vendor vorauszusetzen.

## Installationen und Verhalten prüfen

scripts/test-managed-installations.ps1 installiert die Distribution in frische Verbraucherprojekte. Das Skript prüft alle neun Ziele ohne separates offizielles SDK-Paket, SDK-Quellpfad, kopierten Adapter oder manuelle SDK-Linkkonfiguration. Es kompiliert und führt die exakt erzeugten direkten Verbindungs-Snippets einschließlich maskierter öffentlicher Daten aus und meldet configuration_files_required: false. Sein Bericht ist von der Laufzeitsuite getrennt.

scripts/test-integration-packages.ps1 führt Lebenszyklusregressionen und lokal signierte Real-SDK-Fixtures aus. Toolpfade und einen konfigurierten nativen Testbuild angeben:

```powershell
./scripts/test-integration-packages.ps1 -Python python -DotNet dotnet -JavaHome $env:JAVA_HOME -Ruby ruby -Cargo cargo -NativeBuildDirectory .cache/launch-native-build
```

Repository-Quellbuilds verwenden normale native OS-Abhängigkeiten; Windows-Maintainer können LICENTIVO_CURL_ROOT angeben. Dies ist eine Tool-Einstellung für Quellbuilds, keine separate SDK-Installation. Bei unterschiedlichen Rust-/C++-MinGW-Installationen beschränkt -NativeRuntimeDirectories C++-DLL-Verzeichnisse auf native Prüfungen. Fehlende Voraussetzungen lassen das betroffene Ziel fehlschlagen. all_nine_passed erfordert Erfolg aller neun Prüfungen.

## Speicherung und Abnahme

Sitzungen verwenden standardmäßig den Speicher. Gemerkte Anmeldungen benötigen einen geschützten Store. AES-GCM-Stores benötigen einen 32-Byte-Schlüssel aus einem OS-Tresor, der niemals neben dem Chiffretext gespeichert wird. Passwörter werden niemals dauerhaft gespeichert. Go, Python, C# und natives C/C++ bieten Windows-DPAPI für den aktuellen Benutzer; Java, Node, Rust und Ruby bieten verschlüsselte Stores mit vom Aufrufer verwalteten Schlüsseln.

SDK-Gerätedateien behalten ihr Upstream-Format. Sitzungsverschlüsselung verschlüsselt nicht jede SDK-Datei. Bereichsgebundene Cache-Verzeichnisse für Konto/Produkt/Umgebung einschränken und aus Installern, Protokollen und Versionskontrolle ausschließen. Identitäts-/Konfigurationsänderungen dürfen den Cache eines anderen Kontos nicht wiederverwenden.

Eine ausdrückliche Ablehnung von Sitzung/Berechtigung darf nicht auf Offline zurückfallen. Nur Transportfehler oder HTTP 5xx dürfen eine bestehende kryptografisch geprüfte Berechtigung innerhalb ihrer signierten Richtlinie verwenden. Erstaktivierung, Floating-Plätze und Richtlinien ohne Offline-Betrieb behalten ihre Verbindungsanforderungen.

Lokale Berichte beweisen niemals echte Zahlung, Ausstellung oder externe Aktivierung. Diese Umgebung wurde zurückgestellt; siehe [acceptance.md](/de/launch-documents/acceptance/). Registry-Veröffentlichung und Freigabe für Nicht-Windows-Plattformen erfordern separate Arbeit und Nachweise.