Native Choco Runtime
The Native Choco Runtime is RealmJoin's own in-process package installation engine that replaces the outdated Chocolatey 0.10.3 binary while staying fully compatible with existing packages.
The Native Choco Runtime was introduced with RealmJoin Agent 4.21.6 (Beta). The feature is opt-in: existing clients keep using the classic Chocolatey engine until you explicitly enable the native runtime.
What it is
When the RealmJoin Agent installs software packages outside of Intune (see package installation), it has traditionally relied on Chocolatey as the underlying package engine. RealmJoin shipped a pinned, heavily patched build of the open-source Chocolatey CLI — version 0.10.3 — bundled as choco.exe under C:\ProgramData\chocolatey\.
The Native Choco Runtime replaces that bundled Chocolatey binary with RealmJoin's own, purpose-built implementation that runs in-process inside the RealmJoin service. It shims Chocolatey: it understands the same package format (.nupkg) and behaves the same way from a package author's and administrator's point of view, but it no longer depends on the ageing Chocolatey 0.10.3 codebase.
In other words, packages you already use keep working unchanged — only the engine underneath them changes.
How it works
In-process engine. Package installs run inside the RealmJoin service instead of shelling out to an external
choco.exe. ThechocolateyInstall.ps1of each package is executed in an in-process PowerShell runspace.Isolated storage. The native runtime installs to its own root,
C:\ProgramData\RealmJoin\choco\(withlib\,extensions\, andlogs\subfolders). It never writes to classic Chocolatey's state underC:\ProgramData\chocolatey\and never changes the machine-wideChocolateyInstallenvironment variable. This means the native runtime and a pre-existing classic Chocolatey can coexist on the same device.Automatic dependency resolution. Package dependencies declared in the
.nuspec(such as the RealmJoin Core Choco Extension) are resolved and installed automatically from your configured sources.choco.exeshim. Some package scripts callchoco.exedirectly. To keep those working, the runtime deploys a small shim to%ProgramFiles%\RealmJoin\choco-shim\choco.exethat routes such calls back into the in-process engine instead of to classic Chocolatey. The shim is not added to the systemPATH; it is only made available to package scripts while they run.
Compatibility
The Native Choco Runtime is designed as a drop-in replacement:
Existing RealmJoin packages (including everything from the Package Store) install and uninstall the same way.
Package arguments / params configured in the RealmJoin Portal continue to work.
The RealmJoin Core Choco Extension helper cmdlets used inside package scripts remain available.
RealmJoin ESP / Autopilot are supported: on a fresh device with the native runtime enabled,
winchocopackages are installed natively during enrollment, with their dependencies resolved automatically.
As this runtime is in beta, we recommend validating your most important packages on a pilot ring before rolling it out tenant-wide. Please report any behavioural differences to RealmJoin Support so we can address them before general availability.
How to use it
The runtime is selected through a RealmJoin setting, so you can control it centrally instead of touching individual clients. RealmJoin settings cascade, which means you can set a tenant-wide default and, where needed, override it for specific groups (and the objects within them).
Setting Key: Chocolatey.UseNativeRuntime
Setting Value: true / false
The following settings control the behaviour:
Chocolatey.Enabled
false
RealmJoin manages Chocolatey-typed packages on the device.
Chocolatey.UseNativeRuntime
false
Master switch. When false, installs still go through the classic choco.exe. When true, all winchoco installs go through the in-process native runtime.
Chocolatey.DisableShim
false
Only relevant when UseNativeRuntime = true. When true, any package script that calls an external choco.exe fails loudly instead of being routed through the shim — useful to surface scripts that still reach for an external binary.
Validate your packages
Let the pilot devices run their normal package assignments and upgrades. Confirm that installations succeed and check the logs if anything looks off (see Package Installation Issues).
Configuration follows the same tenant-setting / group-override model as the other agent settings described under General settings (for example the Client Configuration and LAPS Configuration tenant settings).
What is the default
Native Choco Runtime is disabled by default (Chocolatey.UseNativeRuntime = false). Clients continue to use the classic, bundled Chocolatey 0.10.3 engine until an administrator enables the native runtime — either tenant-wide or for a specific group. This lets you adopt the new runtime at your own pace and roll it back just as easily while the feature is in beta.
Migrating existing devices
The native runtime and classic Chocolatey coexist on a device for as long as needed. When you enable the native runtime on a device that already has classic Chocolatey-installed packages:
Existing RealmJoin-managed packages keep working and are not reinstalled just because the runtime changed — their installed state carries over across the switch, so there is no reinstall storm.
New installs and upgrades go through the native runtime; the classic installation stays on disk, untouched, until it is explicitly removed.
Fleet-wide removal of classic Chocolatey is planned as a separate, orchestrated step. Until then, the native runtime is happy to coexist with a leftover classic installation, so there is no hard deadline to clean it up.
For an individual device (for example during support or QA), an administrator can move a machine off classic Chocolatey with the shim's migrate verb from an elevated shell:
choco migrate is an admin helper for a single device (support, dev/QA, one-off cleanup). It is not the mechanism for rolling the change out across a fleet — use the tenant/group settings for that.
Logs & troubleshooting
Native runtime installs write a per-package log to:
(kept to the 10 most recent entries per package). This is separate from classic Chocolatey's C:\ProgramData\chocolatey\logs\. When collecting logs for a support request, include the C:\ProgramData\RealmJoin\ folder as described in Package Installation Issues.
File & path reference
C:\ProgramData\RealmJoin\choco\lib\<id>
Native runtime package install root.
C:\ProgramData\RealmJoin\choco\extensions\<id>
Auto-imported PowerShell helper modules.
C:\ProgramData\RealmJoin\choco\logs\<id>
Per-install logs (last 10 per package).
C:\Program Files\RealmJoin\choco-shim\choco.exe
The choco.exe shim.
Last updated
Was this helpful?