Installing the Microsoft SDK

← xrmverse documentation

The Microsoft SDK (Microsoft.Xrm.Sdk, Microsoft.Crm.Sdk.Proxy, Microsoft.PowerPlatform.Dataverse.Client) is not open source, so xrmverse does not ship it: no image, release archive or package contains it. You download it yourself, once, after accepting Microsoft's license terms. The same goes for the workflow SDK (Microsoft.Xrm.Sdk.Workflow, from the package Microsoft.CrmSdk.Workflow), which only custom workflow activities need. The .NET runtime and the MIT/Apache-licensed packages that xrmverse does ship are not affected.

xrmd sdk install --dir ./xrmd-server     # prompts (default: no) with the license URL, then downloads from nuget.org
xrmd sdk status --dir ./xrmd-server      # version, path and acceptance record (-o json)

Option	Effect
`--accept-microsoft-license`	your explicit acceptance without the prompt; required when stdin is not a terminal (otherwise exit `2`). On `server init` it installs the SDK into `<dir>/sdk` as part of init
`--dir <installation>`	installs into `<installation>/sdk`, which is mounted read-only into every organization's container at `/var/lib/xrmd/sdk` (`XRMD_SDK_DIR` in the image)
`--user`	also (or, without `--dir`, only) installs into the user folder: `~/.xrmd/sdk`, or `XRMD_SDK_DIR`
`--from <file.nupkg>`	offline: the package comes from a file; same hash check, same acceptance. Without `--from-workflow` the workflow SDK is not installed (a note on stderr says so, or says that it was removed from the folder)
`--from-workflow <file.nupkg>`	offline: the workflow package `Microsoft.CrmSdk.Workflow` comes from a file, with its own hash check

Without a file option, install (and server init) downloads both packages after one acceptance, which names both. Nothing is downloaded or extracted before the acceptance. The package Microsoft.PowerPlatform.Dataverse.Client 1.2.27 (the only version supported) is checked against its pinned SHA-512 before anything is extracted, and only the three SDK assemblies are taken, from the package's lib/net10.0/ folder (the install fails, naming that path, if the package has none). The workflow package Microsoft.CrmSdk.Workflow 9.0.2.60 is checked against its own pinned SHA-512 too, and only lib/net462/Microsoft.Xrm.Sdk.Workflow.dll is taken from it. Both hashes are checked before anything is written, and a failure leaves the previous folder as it was. sdk.json in the folder records the version, the hash and when and how (flag or prompt) the terms were accepted, and, when the workflow SDK is installed, workflowPackage, workflowVersion and workflowSha512 (records written without them stay valid). xrmd sdk status shows workflowSdk (the package and version, or missing (run 'xrmd sdk install')), workflowVersion and workflowSha512.

SDK folders installed earlier from lib/net8.0/ keep working on the .NET 10 host and CLI: they hold the same assembly names and versions, so no reinstall is required.

Where it is looked for. The host: Sdk:Path, else XRMD_SDK_DIR, else ~/.xrmd/sdk. The CLI: XRMD_SDK_DIR, else ~/.xrmd/sdk. The default ~/.xrmd/sdk (%USERPROFILE%\.xrmd\sdk on Windows) is the same for both and does not move with XRMD_CONFIG_DIR.

What needs it.

server init offers it ("Install the Microsoft SDK now? [y/N]", default no; without a terminal it only prints the command to run). server up, server upgrade and server org add refuse to start containers (exit 1, with the xrmd sdk install --dir <dir> command) while <dir>/sdk/sdk.json is missing. An old single-service directory is refused too, because its compose file does not mount the SDK folder: migrate it with xrmd server init --force --dir <dir>, then xrmd sdk install --dir <dir>.
The host loads Microsoft.Xrm.Sdk and Microsoft.Crm.Sdk.Proxy from the folder at startup, before anything uses them, and hands that one copy to every plug-in. Without the SDK it exits with code 3 and the message The Microsoft SDK is not installed (looked in <folder>)…; with an SDK folder of another version (sdk.json or the Microsoft.Xrm.Sdk file version) it exits with code 3 naming both versions. In a container of an installation the message says xrmd sdk install: for an installation the command is xrmd sdk install --dir <installation>, run on the Docker host (it fills <installation>/sdk, the folder mounted at /var/lib/xrmd/sdk).
The host does not require the workflow SDK. When Microsoft.Xrm.Sdk.Workflow.dll is in the folder it loads it after Microsoft.Xrm.Sdk; a version or hash that differs from the pinned one is a warning, not a refusal. Without it, the host starts and every custom workflow activity step is an unsupported step naming xrmd sdk install (see Classic workflows).
The CLI loads it only for the commands that use it (data, table, dev, apply, …); without it they print the same message and exit 1. server, auth, sdk, plugin, solution, publisher, user/role, logs and mcp work without it. plugin register reads the plug-in's IPlugin types with the SDK folder's Microsoft.Xrm.Sdk, or from metadata alone when there is none.

Checking it. GET /admin/health reports sdkVersion, and xrmd server doctor (GET /admin/doctor) has an sdk check: an error, naming xrmd sdk install, when the loaded SDK is not the pinned one. Health also reports workflowSdkVersion (null without the workflow SDK), and the doctor's sdk-workflow check is a warning, naming the file, the folder and xrmd sdk install, when the workflow SDK is missing or is not the pinned one. The manual acceptance steps are in the checklist.