Farbschema: Riviera
Sie befinden sich hier: start » en » Documentation » Microsoft Access development tools » WKL Forms Object Library » WKL Forms Object Library how-to guides » How to: Deliver an application for production

How to: Deliver an application for production

Build the copies an application is delivered as - an ACCDE for the Access Runtime, an ACCDE for administrators - each already set up for its mode, with a manifest a setup program can check.

Requires WKL Forms Object Library 1.51 or later, and the build tool of the release package (tools\build).

Solution overview

The build tool builds the application from its text sources (How to: Build an Access application from its text sources). Two entries of access-app.json add the delivery: appModel names the model of the WKL Application Designer (title, icon, start form, ribbon, the user interface of each mode), deploy the version and the targets. For each target the tool copies the ACCDB (development) or the ACCDE, writes the startup properties of the target's mode into the copy with DAO - the copy is never opened, so its start form does not run during the build - and writes app-manifest.json and INSTALL.txt next to it. INSTALL.txt (English and German) is for the administrator of the customer: copy the folder to a local folder of the user (never as an e-mail attachment or a downloaded archive), make it a trusted location with tools\deploy\Set-AccessTrustedLocation.ps1, and check it with tools\deploy\Test-AccessTrust.ps1.

Implementation

  1. Save the model as a file next to the sources, for example with the application designer and then Export-AccessApp.ps1, which writes it as appModel names it, together with the icon file.
  2. Name the model and the delivery in access-app.json:

    {
      "name": "Customers",
      "references": [ { "library": "WklForms", "major": 2, "minor": 0 } ],
      "forms": "src/forms",
      "modules": "src/modules",
      "appModel": "src/app/app-model.json",
      "deploy": { "version": "1.4.0", "targets": ["Administration", "Production"] }
    }
  3. Build: .\tools\build\Build-AccessApp.ps1 -Project .\access-app.json. The output names the ACCDB, the ACCDE and the delivered files, for example deploy\production\Customers.accde. -Target Production builds the production folder only.
  4. Call EnsureApplication in the start form, so that a copy opened in another mode corrects itself (see the tutorial):

    Private Sub Form_Load()
        Dim findings As String
        findings = CreateObject("WklForms.Application").EnsureApplication()
        If Len(findings) > 0 Then Debug.Print findings
    End Sub
  5. Hand deploy\production to the setup that places the application on the users' computers; it checks the file against sha256 of app-manifest.json. Check the copy before Access opens it: Access writes to an ACCDE when it opens it, also with /runtime, and the checksum no longer matches. The checksum shows a damaged copy, not where the file came from: the manifest lies beside the file and can be replaced with it.

Remarks

  • Only in a trusted location. The startup properties act only when Access opens the file with its code trusted. With a stricter macro setting outside a trusted location Access does not open a delivered ACCDE at all, so the properties neither protect nor matter there (see The application opens but its code does not run). Deliver into a trusted location and check a PC with tools\deploy\Test-AccessTrust.ps1.
  • Right at the first opening. The startup properties of the mode are in the delivered file; without deploy, an ACCDE made from the ACCDB carries the development properties until EnsureApplication has run once and the database was opened again.
  • Checking the delivered copy without the runtime. The startup properties can be read from the delivered file without opening it in Access, so a machine without the Access Runtime can still tell whether the production copy is locked down. In 32-bit PowerShell with DAO:

    $engine = New-Object -ComObject DAO.DBEngine.120
    $db = $engine.OpenDatabase("$PWD\deploy\production\Customers.accde", $false, $true)
    foreach ($n in 'StartUpShowDBWindow', 'AllowFullMenus', 'AllowShortcutMenus', 'AllowSpecialKeys', 'AllowBypassKey') {
        try { '{0} = {1}' -f $n, $db.Properties.Item($n).Value } catch { "$n missing" }
    }
    $db.Close()

    With the defaults of production all five are False. This answers whether the delivery is locked; it does not replace a start in the runtime, which also shows the start form and the ribbon.

  • The icon is stored in the database. AppIcon is removed from the delivered copy - it would name a file of the build computer - and EnsureApplication writes the icon as a file of the user's computer at the first start; the icon acts at once.
  • An ACCDE runs only in Access of its bitness; bitness in the manifest says which. A database needs the registered WKL release of its requires version or a newer one (How to: Deploy to user PCs).
  • What deploy does not do: it installs nothing, registers nothing and sets no trusted location (tools\deploy\Set-AccessTrustedLocation.ps1).
  • Not a protection. The locked options keep users from the design by accident; protect the data with the rights of the server.
en/wiki/msaccess/comctl/how-to/deliver-an-application-for-production.txt · Zuletzt geändert: von Wolfgang van der Stille