delivery-settings.json

Die Auslieferung eines Access-Projekts: die Version der Anwendung, ihre Ziele und die Release-Pakete, die eine Auslieferung mitführt. wkl-office deliver und die Gruppe Herausgabe des Add-Ins lesen diese Datei.

delivery\delivery-settings.json im Projektordner, unter Versionsverwaltung:

{
  "format": 2,
  "version": "1.4.0",
  "packages": {
    "components": "%WKL_PACKAGES%\\Wkl.Forms.ObjectLibrary\\2.0.0",
    "json": "%WKL_PACKAGES%\\Wkl.Office.JSON\\2.0.0",
    "bootstrapper": "%WKL_PACKAGES%\\Wkl.Bootstrapper\\3.1.0"
  }
}

Daneben je Auslieferungsprofil eine Datei delivery\<profile>.profile.json:

{ "format": 1, "configuration": "Release" }

Eine Datei je Projekt mit dem, was alle Auslieferungsprofile teilen und das SDK nicht aus den Quellen lesen kann: die Version, die die Auslieferung trägt, und wo die Release-Pakete auf dem Build-Rechner liegen. Jedes Profil ist eine eigene Datei (Auslieferungsprofile). Die eigenen Einstellungen des Starters (Dateien, Registrierung, Verknüpfungen, Bedingungen, die Freigabe, aus der er liest) stehen in seiner Projektdatei je Profil, delivery\<profile>.bootstrapper.json, die mit dem Bootstrapper Manager bearbeitet wird. Eine Datei im Format 1 nennt stattdessen die ausgelieferten Modi als targets; sie gilt weiter.

Sie ist nicht die delivery.json, die WKL Bootstrapper neben eine signierte Auslieferung in den Quellordner schreibt.

Paketpfade dürfen Umgebungsvariablen enthalten (%WKL_PACKAGES%) und relativ zum Projektordner sein; eine Datei bedient so jeden Rechner, auf dem die Pakete an einem anderen Ort liegen. Unbekannte Einträge werden abgelehnt; ein Standardwert wird weggelassen, wenn das SDK die Datei schreibt.

Mit "format": 2 enthält delivery-settings.json nur, was alle Ziele gemeinsam haben (version, publisher, supportEnd, requirePublisher, packages), und keine targets. Jedes Ziel ist eine eigene Datei delivery\<name>.profile.json, wie ein Veröffentlichungsprofil in Visual Studio; deliver und das Add-in nehmen die Profile in der Reihenfolge ihrer Namen.

{
  "format": 1,
  "configuration": "KundeA",
  "starterName": "kunden.exe"
}

• Der Name eines Profils ist sein Dateiname: Buchstaben, Ziffern, Leerzeichen und - _ ., höchstens 64 Zeichen, ohne Leerzeichen oder Punkt am Anfang oder Ende und kein Gerätename von Windows (CON, NUL …). deliver -p <name> liefert ein einzelnes Profil aus.
• Mehrere Profile dürfen denselben Modus ausliefern, zum Beispiel eines je Kunde, jedes mit eigener Konfiguration (Verbindungsprofil) und eigenem Ordner. Ob eine ACCDE ausgeliefert wird, richtet sich wie im Format 1 nach dem Modus: Development liefert eine ACCDB; Accde der Konfiguration ändert das nicht.
• Format 1 bleibt gültig. Seine Ziele werden als Profile mit dem Namen ihres Modus gelesen und in der gleichnamigen Konfiguration gebaut, wenn die Projektdatei eine hat, sonst mit den Einstellungen des Projekts; der Modus ist der des Ziels. Das SDK schreibt eine Datei im Format 1 nicht von sich aus ins Format 2 um; die Projekteigenschaften des Add-ins schreiben Format 2, sobald die Auslieferung dort geändert wird (Access-Add-In verwenden).

• Welche Bibliotheken mitgehen, wird aus den Verweisen des Projekts (source\references.json) gelesen, anhand der GUID ihrer Typbibliothek: WKL Forms Object Library und WKL Office JSON. Verweise auf Access, DAO, VBA oder Office gehören zu Access und werden nicht ausgeliefert.
• Ein Paket wird geprüft, bevor etwas gebaut wird: Beide Bitbreiten müssen vorhanden sein (x86\<dll>, x64\<dll>), und sein Release (aus x86\registration.json, sonst aus dem Ordnernamen) darf nicht älter sein als der Verweis. wkl-office deliver --dependencies listet das Ergebnis auf.
• Runtime und Treiber werden nicht aus den Quellen gelesen: Das SDK kann nicht erkennen, ob auf den Rechnern .NET oder ein Treiber bereits installiert ist; sie gehen daher nur mit, wenn packages sie nennt. Wird die Projektdatei des Starters aus einer Vorlage geschrieben, kommen die Vorlagen dotnet und odbc hinzu; die Vorlage odbc nennt einen Beispieltreiber, den der Entwickler im Bootstrapper Manager durch die hier genannten Treiber ersetzt.
• Ein gewählter Auslieferungsordner wird nur geleert, wenn eine frühere Auslieferung ihn geschrieben hat (er ist leer oder enthält deploy\app-manifest.json); jeder andere Ordner – eine Freigabe, versehentlich der Projektordner – wird abgelehnt und bleibt unverändert.
• bitness: any baut zweimal. Der erste Bau kompiliert den Code zur Prüfung; ein Kompilierfehler beendet die Auslieferung mit Exitcode 4, wie bei build. Der zweite Bau lädt dieselben Quellen ohne zu kompilieren und ist die ausgelieferte Datenbank; sie trägt deshalb keinen Kompilierzustand des bauenden Access. Ihre Starteigenschaften sind die der Betriebsart, wie bei einer ACCDE. Weil eine ACCDB ausgeliefert wird, ist der Code lesbar und änderbar; ist das nicht hinnehmbar, liefern Sie stattdessen je Bitbreite eine ACCDE aus. Der VBA-Code muss in beiden Bitbreiten gültig sein (PtrSafe und LongPtr in Declare-Anweisungen). app-manifest.json nennt "bitness": "any".
• Produktschlüssel je Ziel: Production wird unter dem Projektnamen ausgeliefert, Administration unter dem Namen mit Admin, Development mit Dev; die Kopien auf dem Rechner eines Benutzers ersetzen einander daher nie. Auslieferungsprofile desselben Modus teilen den Produktschlüssel; liefern Sie sie auf verschiedene Rechner aus.

Eine Auslieferung nur für die Produktion, mit Paketen neben dem Projekt:

{
  "format": 1,
  "version": "2.0.0",
  "targets": [ { "mode": "Production" } ],
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.0.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0"
  }
}

Eine Auslieferung auf eine Freigabe, mit umbenanntem Starter, einer privaten Runtime und dem OData-Treiber:

{
  "format": 1,
  "version": "2.0.0",
  "targets": [ { "mode": "Production", "output": "\\\\server\\apps\\Demo", "starterName": "demo.exe" } ],
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0",
    "dotnet": "..\\packages\\dotnet-10",
    "odbc": [ { "driver": "Wkl OData", "folder": "..\\packages\\WklOData" } ]
  }
}

Eine Auslieferung für zwei Kunden im Format 2, jede in ihrer eigenen Konfiguration gebaut (delivery\delivery-settings.json, dann delivery\Kunde A.profile.json und delivery\Kunde B.profile.json):

{
  "format": 2,
  "version": "2.0.0",
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.1.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0"
  }
}

{ "format": 1, "configuration": "KundeA", "output": "\\\\server-a\\apps\\Kunden" }

{ "format": 1, "configuration": "KundeB", "output": "\\\\server-b\\apps\\Kunden" }

Die Konfigurationen in der Projektdatei setzen Modus und Verbindungsprofil je Kunde:

<PropertyGroup Condition="'$(Configuration)' == 'KundeA'">
  <Accde>true</Accde>
  <AppMode>Production</AppMode>
  <ConnectionProfile>PROD-A</ConnectionProfile>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'KundeB'">
  <Accde>true</Accde>
  <AppMode>Production</AppMode>
  <ConnectionProfile>PROD-B</ConnectionProfile>
</PropertyGroup>

• Projektordner – welche Datei wo liegt und was versioniert wird
• Build-Konfiguration und Auslieferungsprofil – was eine Konfiguration und ein Profil festlegen
• Anwendung aus dem SDK ausliefern
• Befehlszeilenreferenz: deliver, msi