How to: Deploy an application with WKL controls to user PCs

Bring an Access application (ACCDB or ACCDE, full Access or the Access Runtime) that uses WKL controls onto the PCs of its users.

Requires any release of the WKL Forms Object Library; the examples use <version> for the folder of the release.

Every user PC needs four things, in this order:

1. The .NET 10 Desktop Runtime in the bitness of Office (or of the Access Runtime).
2. The files of the release in that bitness, in a local folder that stays.
3. The registration of Wkl.Forms.ObjectLibrary.dll for each Windows user who starts the application.
4. The application itself, built against the same release, in a trusted location.

The script below performs steps 2 and 3; step 1 is the installer from Microsoft, step 4 is your own distribution of the front end. To do steps 2 and 3 without a script, use the bootstrapper in the package (see Remarks).

Checklist per PC:

Script for steps 3 and 4 (PowerShell, run by each user; no administrator rights). Set $Source to the folder of the release on your share and $Bitness to x86 for 32-bit Office:

$Version = '1.59'                                 # the release folder (<version>)
$Bitness = 'x86'                                  # 'x64' for 64-bit Office
$Source  = "\\server\share\WKL Forms Object Library\$Version\$Bitness"
$Target  = Join-Path $env:LOCALAPPDATA "WKL\Access Components\$Version\$Bitness"
 
# Only the Access of this session: on a terminal server other users' Access processes are visible too.
$session = (Get-Process -Id $PID).SessionId
Get-Process MSACCESS -ErrorAction SilentlyContinue | Where-Object SessionId -eq $session | ForEach-Object {
    throw 'Close Access first: it keeps a loaded DLL until it exits.'
}
New-Item -ItemType Directory -Force $Target | Out-Null
Copy-Item (Join-Path $Source '*') $Target -Force
 
$regsvr32 = if ($Bitness -eq 'x86') { "$env:windir\SysWOW64\regsvr32.exe" } else { "$env:windir\System32\regsvr32.exe" }
$process = Start-Process $regsvr32 -ArgumentList '/s', '/n', '/i:user', "`"$Target\Wkl.Forms.ObjectLibrary.dll`"" -Wait -PassThru
if ($process.ExitCode -ne 0) { throw "regsvr32 failed with exit code $($process.ExitCode)." }
'WKL Forms Object Library registered.'

Run it from a logon script or a software distribution tool in the user's context, not as another user: the registration lands in the registry of the user who runs it.

Script for step 5, in the same context: Set-AccessTrustedLocation.ps1 writes the entry the Trust Center dialog writes (per Windows user, no administrator rights) and removes it again with -Remove:

$Front = Join-Path $env:LOCALAPPDATA 'Contoso\Orders'      # the folder of the front end
& "\\server\share\WKL Forms Object Library\$Version\tools\deploy\Set-AccessTrustedLocation.ps1" -Path $Front

A folder on a network share needs -AllowNetworkLocations as well, which allows trusted locations on the network for all of the user's entries; a local folder for the front end avoids it. Locations set by policy win: when an administrator has switched trusted locations off, the script warns that its entry has no effect.

• Without a script: the bootstrapper. The package holds bootstrapper\Wkl.Bootstrapper.exe, a starter that does these steps for each user at the start of the application - it copies the version into the user's profile, registers the WKL components for the user, makes the folder a trusted location and starts Access, without administrator rights. See How to: Deliver an application with the bootstrapper. From release 1.56.2 the package holds the bootstrapper 2.0 and, next to each DLL, registration.json (the per-user registration as data): the bootstrapper 2.0 writes and removes these keys itself instead of calling regsvr32, and keeps a release registered while an installed application still needs it.
• ACCDE per release. Build the ACCDE from the ACCDB with the release registered that the users get. A database built against an older release opens with a newer registration (Access resolves the reference when the database opens); an ACCDE cannot be compiled again on the user's PC, so build a new ACCDE whenever you use members of a newer release.
• Order of an update: components first, then the database. An ACCDE built with one release registered runs with a newer release registered (the reference then points to the newer file and is intact). The other way round is not supported: an ACCDE built with a newer release registered, opened on a PC that still has the older one, can have a broken reference (TYPE_E_LIBNOTREGISTERED), and a form with events of a WKL control fails with error 459. On a PC in the middle of an update, the new components with the old database work; the new database with the old components does not. Roll out the components before the database built against them.
• Access Runtime. The controls run in the Access Runtime like in full Access. The runtime has no add-ins: the menu entry of the link manager designer (Database Tools › Add-Ins) is a tool for the developer only; applications call WklLinkManager from their own code.
• Several Windows users on one PC (terminal server, shared PCs): each user runs the script once. A registration for all users of a PC (regsvr32 as administrator without /n /i:user) is not supported in this release.
• Trusted location. The application's VBA runs only in a trusted location or in a trusted database. Outside one, Access asks with its security notice (default macro setting, ACCDE) or switches the code off without a word (stricter settings, an ACCDB in the full version) - see The application opens but its code does not run. A location covers subfolders only with -AllowSubfolders; Test-AccessTrust.ps1 of the package checks a PC before the first start. The ActiveX setting Disable all controls without notification stops the WKL controls also in a trusted location (Access error 2926); the other ActiveX options do not - see the troubleshooting page above.
• Update. To update, close Access on the PC, run the script with the new version and replace the front end built against it. Delete the folder of the old version afterwards.
• Bitness. Both 32-bit and 64-bit Access are supported.

• How to: Install the released package - the same steps on a development PC, with the list of files
• The .NET 10 Desktop Runtime is not installed
• A WKL control or the reference is missing (wrong bitness)
• Access reports that another .NET version is loaded
• The application opens but its code does not run