WKL Office SDK
Color scheme: Dark
Riviera
Light
Dark
You are here: start » de » Dokumentation » Werkzeuge für Microsoft Access » WKL Office SDK » how-to » Projekt des Build-Werkzeugs der WKL Forms Object Library migrieren

Projekt des Build-Werkzeugs der WKL Forms Object Library migrieren

Sie stellen eine Anwendung, die mit Build-AccessApp.ps1 und access-app.json (dem Build-Werkzeug der WKL Forms Object Library) gebaut wird, auf das WKL Office SDK um, sodass sie mit wkl-office und dotnet build gebaut wird und Access und die Quellen auf demselben Stand bleiben.

Lösungsüberblick

wkl-office migrate access-app.json -o <folder> schreibt ein neues Projekt; das alte wird nur gelesen.

access-app.jsonNeues Projekt
name, accdeAssemblyName, Accde
Verweise (WklComponents, WklJSON und andere über die GUID)source/references.json, nach OLE Automation und DAO, die jede neue Datenbank hat und das alte Werkzeug beibehielt
Datenbankeigenschaften (Ja/Nein, Long, Text)source/application/properties.json
Tabellenskripte (*.sql)in einer temporären Datenbank ausgeführt und zurückgelesen: tables/, relations/ und die Zeilen, die die Skripte einfügen, als Startdaten
Module, Klassen, Formulare, Berichte, Abfragen, Makros, Menübänderin dieselben Ordner kopiert, relativ zur neuen Projektdatei; Quellelemente nennen diese Ordner (AccessModule, AccessForm …; siehe Projektdatei: Quellelemente). Ein Ordner außerhalb des Ordners von access-app.json kommt an den Standardort; ein Ordner, der schon der Standardort ist, braucht kein Element.
Design, Modelle mit Symbolan ihre Standardorte kopiert
templateschon ein SDK-Projekt (ein Ordner mit einer .acproj): ohne Kopie als Template benannt, mit seinem Namen, wenn er unterhalb von WKL_ACCESS_TEMPLATES gefunden wird, sonst mit seinem relativen Pfad; nur im alten Format: in den Ordner template des neuen Projekts migriert und als Template benannt; nicht gefunden: mit seinem Namen als Template benannt, mit Hinweis, der Bau bricht ab, bis WKL_ACCESS_TEMPLATES seinen Ordner nennt
finishFinish
controlBlocksControlBlocks
deploy, outputnicht übernommen (ein Hinweis wird ausgegeben): Die Auslieferung ist Aufgabe von WKL Bootstrapper

Umsetzung

wkl-office migrate C:\Old\Kunden\access-app.json -o C:\Work\Kunden
cd C:\Work\Kunden
wkl-office build Kunden.acproj
wkl-office export Kunden.acproj
wkl-office roundtrip Kunden.acproj

Exportieren Sie nach dem ersten Build einmal und committen Sie das Ergebnis: Access schreibt Formulare und Module einmalig auf seine eigene Weise. Ab dann endet roundtrip mit 0.

Hinweise

  • WKL Forms Object Library 2.0. migrate mit -o übernimmt den Verweis des alten Projekts, auch einen auf Release 1.x (WklComponents). Ist auf dem PC Release 2.0 registriert, bricht build dann ab, weil die Typbibliothek nicht in der verlangten Version registriert ist. Stellen Sie das neue Projekt in diesem Fall zuerst mit wkl-office migrate Kunden.acproj (ohne -o) an Ort und Stelle auf Release 2.0 um, siehe `migrate`.
  • Platzhalter. Formulare mit Platzhalter-Rechtecken (Tag wkl:<Kind>) benötigen die Steuerelementbausteine von WKL Forms Object Library. Das alte Werkzeug nahm sie aus seinem eigenen Ordner; migrate kann nicht wissen, wo das war. Es trägt den Ordner control-blocks oder docs/control-blocks zwei Ordner oberhalb von access-app.json ein, wenn es einen solchen gibt (also für die Vorlagen im Release-Paket und im Repository der WKL Forms Object Library); andernfalls gibt es einen Hinweis aus. Nennen Sie dann den Ordner des Release-Pakets als ControlBlocks oder in der Umgebungsvariablen WKL_ACCESS_CONTROL_BLOCKS.
  • Auslieferung. Die deploy-Ziele des alten Werkzeugs haben im SDK keine Entsprechung; eine Konfiguration mit Accde und AppMode erzeugt die ACCDE mit den Starteigenschaften eines Modus, und WKL Bootstrapper liefert sie aus. wkl-office deliver schreibt die Auslieferung samt ihrer app-manifest.json (Format 1, wie WKL Bootstrapper sie liest) aus delivery\delivery-settings.json: siehe Anwendung aus dem SDK ausliefern. Eine Anwendung, die ihr Manifest nach dem Build selbst geschrieben hat, kann diesen Schritt weglassen.
  • Leere Texte. Die Textfelder der migrierten Tabellen erhalten in ihrem Schema allowZeroLength: true: Die Tabellen, die das alte Werkzeug mit CREATE TABLE anlegte, akzeptierten "", und ein ohne diese Angabe gebautes Feld weist es mit Fehler 3315 zurück (siehe „Felder eines Tabellenschemas“ in der Quellstruktur).

Verwandte Themen

de/wiki/msaccess/sdk/how-to/migrate-from-the-build-tool.txt · Last modified: by Wolfgang van der Stille