microsoft/aspire · error · InvalidOperationException

New CLI executable failed verification test.

Error message

New CLI executable failed verification test.

What it means

After replacing the running executable, the self-update runs the new binary to read its version as a smoke test. If the new binary does not report a version (crash, missing dependencies, truncated file), the update is considered failed and an InvalidOperationException is thrown.

Solutions

1. Run the new `aspire --version` manually to see the underlying failure
2. Re-run `aspire update --self` (or reinstall via the installer script) to rewrite the binary
3. Check antivirus/quarantine logs and whitelist the install directory
4. Ensure the install directory is on a filesystem that allows executing newly written files (no noexec mounts)

var probe = Process.Start(new ProcessStartInfo(targetExe, "--version") { RedirectStandardOutput = true });
probe.WaitForExit(10000);
if (probe.ExitCode != 0) Console.Error.WriteLine("New binary failed smoke test before update.");

try { await UpdateSelfAsync(); }
catch (InvalidOperationException ex) when (ex.Message.Contains("failed verification test"))
{ Console.Error.WriteLine("Run 'aspire --version' to see the real failure; reinstall if needed."); }

When it happens

Trigger: `aspire update --self` where the freshly replaced `aspire` binary cannot execute and print its version — e.g. corrupted extraction, incompatible binary for the platform, missing runtime prerequisites, or the file being quarantined by antivirus.

Common situations: AV/EDR quarantining newly written executables, partially written binaries on flaky filesystems, network-mounted install directories with exec restrictions, or cross-architecture archives.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Cannot write to installation directory
• Extracted CLI executable not found
• Unable to determine current CLI location.
• Unable to determine installation directory from
• Already connected to AppHost backchannel.

AI-assisted analysis of microsoft/aspire@25830f84bd (2026-09-16). Data as JSON: /api/errors/ba6c9d91ad891ab5. Report an issue: GitHub.

Appendix: source

Thrown at src/Aspire.Cli/Commands/UpdateCommand.cs:828

            try
            {
                // Copy new executable to install location
                InteractionService.DisplayMessage(KnownEmojis.Wrench, $"Installing new CLI to {installDir}...");
                File.Copy(newExePath, targetExePath, overwrite: true);

                // On Unix systems, ensure the executable bit is set
                if (!_environment.IsWindows())
                {
                    SetExecutablePermission(targetExePath);
                }

                // Test the new executable and display its version
                _logger.LogDebug("Testing new CLI executable and displaying version");
                var newVersion = await GetNewVersionAsync(targetExePath, cancellationToken);
                if (newVersion is null)
                {
                    throw new InvalidOperationException("New CLI executable failed verification test.");
                }

                // The new binary will extract its embedded bundle on first run via EnsureExtractedAsync.
                // No proactive extraction needed — the payload is inside the new binary's embedded resources,
                // which are only accessible when that binary is running.

                // Display helpful message about PATH
                if (!IsInPath(installDir, _environment))
                {
                    InteractionService.DisplayMessage(KnownEmojis.Information, $"Note: {installDir} is not in your PATH. Add it to use the updated CLI globally.");
                }

                // Shared staging archives can contain a ship-candidate binary deliberately stamped
                // as stable. Persist the channel selected by this update so the next invocation keeps
                // using staging instead of falling back to the binary stamp. Remove any sidecar version
                // and commit assigned to the previous executable so identity falls back to the replacement
                // binary's metadata. Commit while the executable backup still exists so a sidecar
                // failure restores the previous CLI.

View on GitHub (pinned to 25830f84bd)