v0.1.6

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.6 (2026-06-06)

Added

• Opt-in child-process environment isolation. ToolInvocationRequest.InheritEnvironmentVariables and LaunchRequest.InheritEnvironmentVariables now default to true for dnx compatibility, but embedders can set them to false when launching untrusted tools or MCP servers that should only receive explicit environment values. ToolEnvironment.GetDefaultEnvironmentVariables() returns a curated platform baseline (PATH, home/profile, temp, and system-directory variables) for hosts that disable full inheritance but still need normal process startup behavior.

v0.1.5 (2026-05-23)

Added

• ToolCacheIndexStore.EvictAsync(packageId, ct) — first-class API for removing one package's pinned state from _index.json so the next resolve falls through to a fresh NuGet metadata query regardless of the CachedWithRefresh TTL. Idempotent (missing entries return false without throwing) and case-insensitive on the package id. Intended for host UIs that expose a manual "update to latest" action — clearing a single pin lets users bypass the 24h cache wait without losing the rest of the cache or flushing the entire index. Previously the same effect required hosts to call UpdateAsync with a mutator that knew the schema details (lowercase keys, OrdinalIgnoreCase dictionary, ToolPackageState, SchemaVersion); EvictAsync encapsulates that.

v0.1.4 (2026-05-19)

Fixed

• Runtime TFM selection now follows the installed host runtime. NuGetToolExtractor no longer assumes net10.0 when selecting tools/{tfm}/{rid}. It derives the host framework from the highest installed Microsoft.NETCore.App runtime reported by DotnetEnvironment, falling back to the current process runtime only if runtime detection data is unavailable.
• Cache hits honor the current version request. CachedOnly and CachedWithRefresh no longer return a pinned prerelease when prerelease is disallowed, or a pinned version outside the requested VersionConstraint.
• Downloads reuse the supplied NuGet.Config. When the CLI is invoked with --configfile, the extractor now loads the same config file for package download that the resolver used for metadata resolution.

v0.1.3 (2026-05-19)

Fixed

• RestrictToSource and AdditionalSources were silently broken. NuGetPackageResolver.BuildSources passed the PackageSource constructor's (string source, string name) arguments in reverse — the literal strings "restricted" and "additional-N" ended up in the URL slot, producing SourceRepository instances backed by invalid endpoints. MetadataResource.GetVersions(...) returned empty version lists, surfacing as PackageNotFoundException even for packages that exist and are listed on the configured feed. Any caller setting either option in v0.1.0–0.1.2 should upgrade.
• NuGetToolExtractor fallback source — the same (name, source) ordering bug was present on the fallback path used when the resolved source URL is not among the user's configured NuGet sources. This path runs whenever resolution succeeded via AdditionalSources or RestrictToSource against a feed the extractor cannot see in NuGet.Config — common for embedders that bootstrap their own source list on fresh installs without a user-level NuGet.Config.

Argument order is now new PackageSource(url, name) matching the NuGet API. No public API change; one-line fix on each of three sites.

v0.1.2 (2026-05-18)

Added

• ToolInvocationRequest.VersionConstraint — optional NuGet version range (e.g. "2.*", "[2.0.0,3.0.0)") is now forwarded to the underlying PackageResolutionRequest. Previously the field was absent and the runner pinned major versions only by passing a fully-qualified ExplicitVersion. Embedders can now express "latest within major 2" without pre-resolving themselves.
• ToolInvocationRequest.AdditionalEnvironment — optional IReadOnlyDictionary<string, string?> of environment variables for the child process is now forwarded to LaunchRequest.AdditionalEnvironment. Required for scenarios that hand credentials or other secrets to the launched tool via env vars (the same pattern used by stdio MCP servers).

Both fields are pure pass-through additions — backwards compatible. Existing callers that omit the new fields see identical behavior to v0.1.1.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.6 (2026-06-06)

Added

• Environment isolation flags. --no-inherit-env prevents the launched tool from receiving the full ambient environment, while seeding it with ToolHost's curated default baseline. --env KEY=VALUE and --unset-env KEY apply explicit child-process environment overrides. Default behavior remains unchanged and continues to match dnx: tools inherit the caller's environment.

v0.1.5 (2026-05-23)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.5. Adds ToolCacheIndexStore.EvictAsync(packageId, ct) for host UIs that surface a manual "update to latest" action against the CachedWithRefresh TTL — bypasses the 24h wait for a single package without flushing the rest of the cache. CLI surface itself unchanged: no new subcommand, no new flag. Version bump exists to keep CLI and library on a single shared version line — same pattern as v0.1.2 (library-only addition, lockstep release).

v0.1.4 (2026-05-19)

Fixed

• Tool arguments are now accepted and forwarded. fcdnx dotnetsay hello no longer fails argument parsing before ToolHost starts. Unmatched tokens after the package id are treated as tool arguments and passed through to the launched process.
• Library re-pinned to FieldCure.ToolHost 0.1.4. This pulls in runtime-aware tool TFM selection, cache constraint validation, and --configfile reuse during package download.

v0.1.3 (2026-05-19)

Fixed (via embedded library)

• Library re-pinned to FieldCure.ToolHost 0.1.3. This release fixes a library bug where --source and --add-source were silently inoperative: the resolver passed PackageSource constructor arguments in reverse, producing SourceRepository instances pointing at the literal strings "restricted" / "additional-N" instead of the supplied URLs, which surfaced as PackageNotFoundException. CLI users of either flag on v0.1.0–0.1.2 saw spurious "package not found" failures; the CLI passed the values through correctly, the library was at fault. CLI surface itself unchanged.

v0.1.2 (2026-05-18)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.2. Adds VersionConstraint and AdditionalEnvironment pass-through on ToolInvocationRequest for library embedders. CLI surface unchanged — no new flags, no behavior change. Version bump exists to keep CLI and library on a single shared version line.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, `--add-sourc...

v0.1.5

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.5 (2026-05-23)

Added

• ToolCacheIndexStore.EvictAsync(packageId, ct) — first-class API for removing one package's pinned state from _index.json so the next resolve falls through to a fresh NuGet metadata query regardless of the CachedWithRefresh TTL. Idempotent (missing entries return false without throwing) and case-insensitive on the package id. Intended for host UIs that expose a manual "update to latest" action — clearing a single pin lets users bypass the 24h cache wait without losing the rest of the cache or flushing the entire index. Previously the same effect required hosts to call UpdateAsync with a mutator that knew the schema details (lowercase keys, OrdinalIgnoreCase dictionary, ToolPackageState, SchemaVersion); EvictAsync encapsulates that.

v0.1.4 (2026-05-19)

Fixed

• Runtime TFM selection now follows the installed host runtime. NuGetToolExtractor no longer assumes net10.0 when selecting tools/{tfm}/{rid}. It derives the host framework from the highest installed Microsoft.NETCore.App runtime reported by DotnetEnvironment, falling back to the current process runtime only if runtime detection data is unavailable.
• Cache hits honor the current version request. CachedOnly and CachedWithRefresh no longer return a pinned prerelease when prerelease is disallowed, or a pinned version outside the requested VersionConstraint.
• Downloads reuse the supplied NuGet.Config. When the CLI is invoked with --configfile, the extractor now loads the same config file for package download that the resolver used for metadata resolution.

v0.1.3 (2026-05-19)

Fixed

• RestrictToSource and AdditionalSources were silently broken. NuGetPackageResolver.BuildSources passed the PackageSource constructor's (string source, string name) arguments in reverse — the literal strings "restricted" and "additional-N" ended up in the URL slot, producing SourceRepository instances backed by invalid endpoints. MetadataResource.GetVersions(...) returned empty version lists, surfacing as PackageNotFoundException even for packages that exist and are listed on the configured feed. Any caller setting either option in v0.1.0–0.1.2 should upgrade.
• NuGetToolExtractor fallback source — the same (name, source) ordering bug was present on the fallback path used when the resolved source URL is not among the user's configured NuGet sources. This path runs whenever resolution succeeded via AdditionalSources or RestrictToSource against a feed the extractor cannot see in NuGet.Config — common for embedders that bootstrap their own source list on fresh installs without a user-level NuGet.Config.

Argument order is now new PackageSource(url, name) matching the NuGet API. No public API change; one-line fix on each of three sites.

v0.1.2 (2026-05-18)

Added

• ToolInvocationRequest.VersionConstraint — optional NuGet version range (e.g. "2.*", "[2.0.0,3.0.0)") is now forwarded to the underlying PackageResolutionRequest. Previously the field was absent and the runner pinned major versions only by passing a fully-qualified ExplicitVersion. Embedders can now express "latest within major 2" without pre-resolving themselves.
• ToolInvocationRequest.AdditionalEnvironment — optional IReadOnlyDictionary<string, string?> of environment variables for the child process is now forwarded to LaunchRequest.AdditionalEnvironment. Required for scenarios that hand credentials or other secrets to the launched tool via env vars (the same pattern used by stdio MCP servers).

Both fields are pure pass-through additions — backwards compatible. Existing callers that omit the new fields see identical behavior to v0.1.1.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.5 (2026-05-23)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.5. Adds ToolCacheIndexStore.EvictAsync(packageId, ct) for host UIs that surface a manual "update to latest" action against the CachedWithRefresh TTL — bypasses the 24h wait for a single package without flushing the rest of the cache. CLI surface itself unchanged: no new subcommand, no new flag. Version bump exists to keep CLI and library on a single shared version line — same pattern as v0.1.2 (library-only addition, lockstep release).

v0.1.4 (2026-05-19)

Fixed

• Tool arguments are now accepted and forwarded. fcdnx dotnetsay hello no longer fails argument parsing before ToolHost starts. Unmatched tokens after the package id are treated as tool arguments and passed through to the launched process.
• Library re-pinned to FieldCure.ToolHost 0.1.4. This pulls in runtime-aware tool TFM selection, cache constraint validation, and --configfile reuse during package download.

v0.1.3 (2026-05-19)

Fixed (via embedded library)

• Library re-pinned to FieldCure.ToolHost 0.1.3. This release fixes a library bug where --source and --add-source were silently inoperative: the resolver passed PackageSource constructor arguments in reverse, producing SourceRepository instances pointing at the literal strings "restricted" / "additional-N" instead of the supplied URLs, which surfaced as PackageNotFoundException. CLI users of either flag on v0.1.0–0.1.2 saw spurious "package not found" failures; the CLI passed the values through correctly, the library was at fault. CLI surface itself unchanged.

v0.1.2 (2026-05-18)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.2. Adds VersionConstraint and AdditionalEnvironment pass-through on ToolInvocationRequest for library embedders. CLI surface unchanged — no new flags, no behavior change. Version bump exists to keep CLI and library on a single shared version line.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.

v0.1.4

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.4 (2026-05-19)

Fixed

• Runtime TFM selection now follows the installed host runtime. NuGetToolExtractor no longer assumes net10.0 when selecting tools/{tfm}/{rid}. It derives the host framework from the highest installed Microsoft.NETCore.App runtime reported by DotnetEnvironment, falling back to the current process runtime only if runtime detection data is unavailable.
• Cache hits honor the current version request. CachedOnly and CachedWithRefresh no longer return a pinned prerelease when prerelease is disallowed, or a pinned version outside the requested VersionConstraint.
• Downloads reuse the supplied NuGet.Config. When the CLI is invoked with --configfile, the extractor now loads the same config file for package download that the resolver used for metadata resolution.

v0.1.3 (2026-05-19)

Fixed

• RestrictToSource and AdditionalSources were silently broken. NuGetPackageResolver.BuildSources passed the PackageSource constructor's (string source, string name) arguments in reverse — the literal strings "restricted" and "additional-N" ended up in the URL slot, producing SourceRepository instances backed by invalid endpoints. MetadataResource.GetVersions(...) returned empty version lists, surfacing as PackageNotFoundException even for packages that exist and are listed on the configured feed. Any caller setting either option in v0.1.0–0.1.2 should upgrade.
• NuGetToolExtractor fallback source — the same (name, source) ordering bug was present on the fallback path used when the resolved source URL is not among the user's configured NuGet sources. This path runs whenever resolution succeeded via AdditionalSources or RestrictToSource against a feed the extractor cannot see in NuGet.Config — common for embedders that bootstrap their own source list on fresh installs without a user-level NuGet.Config.

Argument order is now new PackageSource(url, name) matching the NuGet API. No public API change; one-line fix on each of three sites.

v0.1.2 (2026-05-18)

Added

• ToolInvocationRequest.VersionConstraint — optional NuGet version range (e.g. "2.*", "[2.0.0,3.0.0)") is now forwarded to the underlying PackageResolutionRequest. Previously the field was absent and the runner pinned major versions only by passing a fully-qualified ExplicitVersion. Embedders can now express "latest within major 2" without pre-resolving themselves.
• ToolInvocationRequest.AdditionalEnvironment — optional IReadOnlyDictionary<string, string?> of environment variables for the child process is now forwarded to LaunchRequest.AdditionalEnvironment. Required for scenarios that hand credentials or other secrets to the launched tool via env vars (the same pattern used by stdio MCP servers).

Both fields are pure pass-through additions — backwards compatible. Existing callers that omit the new fields see identical behavior to v0.1.1.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.4 (2026-05-19)

Fixed

• Tool arguments are now accepted and forwarded. fcdnx dotnetsay hello no longer fails argument parsing before ToolHost starts. Unmatched tokens after the package id are treated as tool arguments and passed through to the launched process.
• Library re-pinned to FieldCure.ToolHost 0.1.4. This pulls in runtime-aware tool TFM selection, cache constraint validation, and --configfile reuse during package download.

v0.1.3 (2026-05-19)

Fixed (via embedded library)

• Library re-pinned to FieldCure.ToolHost 0.1.3. This release fixes a library bug where --source and --add-source were silently inoperative: the resolver passed PackageSource constructor arguments in reverse, producing SourceRepository instances pointing at the literal strings "restricted" / "additional-N" instead of the supplied URLs, which surfaced as PackageNotFoundException. CLI users of either flag on v0.1.0–0.1.2 saw spurious "package not found" failures; the CLI passed the values through correctly, the library was at fault. CLI surface itself unchanged.

v0.1.2 (2026-05-18)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.2. Adds VersionConstraint and AdditionalEnvironment pass-through on ToolInvocationRequest for library embedders. CLI surface unchanged — no new flags, no behavior change. Version bump exists to keep CLI and library on a single shared version line.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.

v0.1.3

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.3 (2026-05-19)

Fixed

• RestrictToSource and AdditionalSources were silently broken. NuGetPackageResolver.BuildSources passed the PackageSource constructor's (string source, string name) arguments in reverse — the literal strings "restricted" and "additional-N" ended up in the URL slot, producing SourceRepository instances backed by invalid endpoints. MetadataResource.GetVersions(...) returned empty version lists, surfacing as PackageNotFoundException even for packages that exist and are listed on the configured feed. Any caller setting either option in v0.1.0–0.1.2 should upgrade.
• NuGetToolExtractor fallback source — the same (name, source) ordering bug was present on the fallback path used when the resolved source URL is not among the user's configured NuGet sources. This path runs whenever resolution succeeded via AdditionalSources or RestrictToSource against a feed the extractor cannot see in NuGet.Config — common for embedders that bootstrap their own source list on fresh installs without a user-level NuGet.Config.

Argument order is now new PackageSource(url, name) matching the NuGet API. No public API change; one-line fix on each of three sites.

v0.1.2 (2026-05-18)

Added

• ToolInvocationRequest.VersionConstraint — optional NuGet version range (e.g. "2.*", "[2.0.0,3.0.0)") is now forwarded to the underlying PackageResolutionRequest. Previously the field was absent and the runner pinned major versions only by passing a fully-qualified ExplicitVersion. Embedders can now express "latest within major 2" without pre-resolving themselves.
• ToolInvocationRequest.AdditionalEnvironment — optional IReadOnlyDictionary<string, string?> of environment variables for the child process is now forwarded to LaunchRequest.AdditionalEnvironment. Required for scenarios that hand credentials or other secrets to the launched tool via env vars (the same pattern used by stdio MCP servers).

Both fields are pure pass-through additions — backwards compatible. Existing callers that omit the new fields see identical behavior to v0.1.1.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.3 (2026-05-19)

Fixed (via embedded library)

• Library re-pinned to FieldCure.ToolHost 0.1.3. This release fixes a library bug where --source and --add-source were silently inoperative: the resolver passed PackageSource constructor arguments in reverse, producing SourceRepository instances pointing at the literal strings "restricted" / "additional-N" instead of the supplied URLs, which surfaced as PackageNotFoundException. CLI users of either flag on v0.1.0–0.1.2 saw spurious "package not found" failures; the CLI passed the values through correctly, the library was at fault. CLI surface itself unchanged.

v0.1.2 (2026-05-18)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.2. Adds VersionConstraint and AdditionalEnvironment pass-through on ToolInvocationRequest for library embedders. CLI surface unchanged — no new flags, no behavior change. Version bump exists to keep CLI and library on a single shared version line.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.

v0.1.2

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.2 (2026-05-18)

Added

• ToolInvocationRequest.VersionConstraint — optional NuGet version range (e.g. "2.*", "[2.0.0,3.0.0)") is now forwarded to the underlying PackageResolutionRequest. Previously the field was absent and the runner pinned major versions only by passing a fully-qualified ExplicitVersion. Embedders can now express "latest within major 2" without pre-resolving themselves.
• ToolInvocationRequest.AdditionalEnvironment — optional IReadOnlyDictionary<string, string?> of environment variables for the child process is now forwarded to LaunchRequest.AdditionalEnvironment. Required for scenarios that hand credentials or other secrets to the launched tool via env vars (the same pattern used by stdio MCP servers).

Both fields are pure pass-through additions — backwards compatible. Existing callers that omit the new fields see identical behavior to v0.1.1.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.2 (2026-05-18)

Changed

• Library re-pinned to FieldCure.ToolHost 0.1.2. Adds VersionConstraint and AdditionalEnvironment pass-through on ToolInvocationRequest for library embedders. CLI surface unchanged — no new flags, no behavior change. Version bump exists to keep CLI and library on a single shared version line.

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.

v0.1.1

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.1 (2026-05-18)

Fixed

• Package metadata — projectUrl and repository URLs now point at the actual GitHub repository (fieldcure/fieldcure-toolhost) instead of the spec's draft path (FieldCure/ToolHost, which 404s). No code changes; nupkg contents byte-identical to v0.1.0 except the nuspec URLs.

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.

v0.1.0

ToolHost

Release Notes — FieldCure.ToolHost

v0.1.0 (2026-05-18)

Initial release.

• DnxLiteRunner — primary orchestrator. Resolves a NuGet package id, ensures it is extracted into the standard NuGet global packages folder, and launches the tool with stdio redirected. Single execution path regardless of whether the .NET 10 SDK with dnx is installed.
• DotnetEnvironment.DetectAsync — probes installed SDKs/runtimes, the NuGet global packages folder, and the host RID. Used for diagnostics and warm-cache hints.
• Three-tier version policy — AlwaysLatest, CachedWithRefresh (24h TTL default), CachedOnly. Library default is CachedWithRefresh for cold-start-sensitive embedders.
• Cache shared with dotnet / dnx — installs land in the standard NuGet global packages folder (resolved via SettingsUtility.GetGlobalPackagesFolder). Our metadata sits in %LOCALAPPDATA%/FieldCure/ToolHost/_index.json and is written atomically.
• NuGetToolExtractor — uses DownloadResource.GetDownloadResourceResultAsync against the configured NuGet sources; picks the best-matching tools/{tfm}/{rid}/ folder via FrameworkReducer with host-RID preference and any-RID fallback.
• ToolLauncher — managed (dotnet exec) and self-contained (direct invoke) runners; DOTNET_ROLL_FORWARD=LatestMajor when AllowRollForward is set.
• CredentialProviderSetup.Register — wires the standard NuGet credential plugin discovery (env vars, ~/.nuget/plugins, dotnet CLI plugin folder). Idempotent.
• DotnetToolSettings.Parse — XML parser for the DotnetToolSettings.xml schema (managed and executable runners).
• Targets — net8.0 and net10.0 (both LTS).

Known limitations (v0.1)

• Platform-specific tool packages (non-any RIDs) are best-effort — full RID-graph traversal lands in v0.2.
• Self-contained / NativeAOT tools (Runner = "executable") supported by the launcher but extractor RID selection is best-effort.

---

ToolHost.Cli

Release Notes — FieldCure.ToolHost.Cli (fcdnx)

v0.1.0 (2026-05-18)

Initial release. fcdnx is a drop-in dnx / dotnet tool execute replacement for environments without the .NET 10 SDK.

dotnet tool install -g FieldCure.ToolHost.Cli
fcdnx dotnetsay

Flag matrix (v0.1)

Flag	Status
<PACKAGE_ID>[@VERSION]	✓
--tool-package-version	✓
--prerelease	✓
--source, --add-source	✓
--configfile	✓
--ignore-failed-sources	✓
--no-cache, --no-http-cache	△ parsed, not yet wired
--interactive	✓
--allow-roll-forward	✓
--verbosity	✓
--framework	△ parsed, not yet wired
--arch, --os	△ best-effort in v0.1
--policy (ToolHost extension)	✓
-y/--yes, -h/--help, --version	✓
-- separator → tool args	✓

Exit codes (sysexits.h convention)

Code	Meaning
0	Tool exited with code 0
(tool's)	Tool exited non-zero (passed through)
64	Usage error
65	Package not found
66	No compatible tools/{tfm}/{rid} folder
67	Network / auth error
68	Extraction failed
69	Tool process failed to start
70	Internal error

Targets

• net8.0 and net10.0 (both LTS). Roll-forward enabled, so the tool runs on any installed .NET 8+ runtime.