Frequently asked questions
Frequently asked questions
Section titled “Frequently asked questions”Is XrmGhost an alternative to FakeXrmEasy?
Section titled “Is XrmGhost an alternative to FakeXrmEasy?”Not for what FakeXrmEasy is best at. FakeXrmEasy is a test framework: an in-memory implementation of the Dataverse SDK that your unit tests call in process, so hundreds of cases can run on every commit. XrmGhost is an execution loop: it runs your compiled plugin assembly in a separate process against one scenario file and returns traces and an outcome, so a coding agent, or a developer with a debugger attached, can write, run and fix without deploying. Different moments of the same day; many teams will want both.
FakeXrmEasy, XrmMockup and XrmGhost compared
Does it run the real plugin or a mock?
Section titled “Does it run the real plugin or a mock?”Your plugin, compiled. The host loads the assembly you built and calls your plugin class in a .NET Framework 4.7.2 process shaped like the Dataverse server-side plugin model. Everything around it comes from the scenario file: execution context, input parameters, pre- and post-images, and the data your code reads. On Pro, Retrieve and RetrieveMultiple can be answered read-only by a live environment instead. It is not Dataverse: one plugin type runs per run, other plugins registered on the same message do not fire, and a request sent through Execute that the host does not handle throws NotImplementedException. The gap is visible, not silent.
Is it Windows only?
Section titled “Is it Windows only?”Yes. A run needs Windows x64 with .NET Framework 4.7.2. Dataverse plugins are .NET Framework assemblies and the host that executes them is a .NET Framework 4.7.2 process; on Windows 10 and 11 the framework is almost always already installed. The xg CLI is a .NET 9 application, but every run goes through the host, so a macOS or Linux machine cannot run plugins with XrmGhost, and neither can a Linux build agent. Plan for a Windows machine wherever plugins run, including the build agent if you use XrmGhost in CI.
What does my coding agent actually do with it?
Section titled “What does my coding agent actually do with it?”With the XrmGhost skills installed, your agent runs the loop you would otherwise run by hand. It writes a scenario file (the message, the data your code reads, the outcome you expect), runs it with xg run, reads the result and the plugin traces, and reports pass or fail with the key signal. Then it offers three paths: look at the code, look at the scenario, or iterate on its own for a few bounded rounds, saying what it changed each time. It is told never to weaken an assertion to turn a run green. The skills follow the Agent Skills standard and work with Claude Code, GitHub Copilot CLI, Codex CLI, OpenCode and others.
Do I need a license to try it?
Section titled “Do I need a license to try it?”Not to start. Without an API key, xg run executes your plugin against the data in the scenario. xg license status shows Standard Unlicensed until you add a key. The license lets your organization use it for 60 days, for up to three people and for internal use only. After that, or for production or client work, you need one of the two editions. Standard covers the whole local loop with scenario data, production use and client work included. Pro adds everything that touches a live environment: read-only data from your environments during a run, a library of environments and connections, and use in a CI pipeline.
What leaves my machine?
Section titled “What leaves my machine?”No plugin code, no plugin output and no Dataverse records. Three things are sent. Machine registration, at every start: a random Platform ID, hashed machine and user names, OS and versions; licensing depends on it, so it stays on. Usage telemetry: one record per command, with the command, result, duration and whether a person, an agent or a CI pipeline ran it. Run diagnostics: timings and outcome of each xg run. One field, the error message of a failed command, is free text and can contain a file path or your environment URL. XRMGHOST_TELEMETRY=0 turns off telemetry and diagnostics; xg privacy prints a summary.
Privacy: what is sent, field by field
Can I use it in CI?
Section titled “Can I use it in CI?”Yes, with limits worth knowing first. Use in a CI pipeline is a Pro capability. The build agent must be Windows with .NET Framework 4.7.2; on build agents XrmGhost installs as a .NET global tool from NuGet, which also needs the .NET 9 runtime. xg run --no-interactive runs one scenario per invocation and exits 0 or 1, after checking the scenario’s expected exception and expected traces. A suite is a loop of invocations in your pipeline script; there is no built-in test report. For hundreds of fast regression cases on every commit, an in-process test framework is the better fit.
Does it work with Power Automate or Custom APIs?
Section titled “Does it work with Power Automate or Custom APIs?”Custom APIs, yes. The main operation of a Custom API is a plugin, so it runs like any other: the scenario uses the API’s unique name as the message, puts each request parameter directly under the input parameters, and has no Target and no primary entity. XrmGhost does not run Power Automate flows. If a flow triggers your plugin, by changing a record or by calling your Custom API, the scenario describes that message and your plugin runs against it; the flow stays in the cloud. Custom workflow activities are not supported yet.
How do I report a bug?
Section titled “How do I report a bug?”Open an issue in the public repository using the bug form. It asks for the output of xg --version, your Windows version, the output of xg doctor, the command you ran, what you expected and what happened. The most useful thing to attach is a scenario file that reproduces the problem with the smallest plugin you can share: a scenario is self-contained, so we can run what you ran. Remove customer data from it first. Questions that are not bugs go to GitHub Discussions.