Skip to content

v0.3.0

Choose a tag to compare

View all tags
@kzu kzu released this 15 Aug 02:33
· 17 commits to main since this release
v0.3.0
7f2541f

Share the NuGet global packages cache with dnx and restore, and fail clearly when a framework-dependent tool needs a newer runtime than the host dotnet.

NuGet v3 cache

ndnx now installs one-shot tools into the same folder restore uses (NUGET_PACKAGES, nuget.config's globalPackagesFolder, or ~/.nuget/packages). NDNX_STORE still overrides that for isolated runs.

The on-disk layout matches NuGet, not a private .ndnx-ok dump:

  • {id}/{version}/{id}.{version}.nupkg
  • {id}.{version}.nupkg.sha512 is Base64(SHA512(nupkg bytes)) — the restore algorithm, not dnx's nuspec-hash shortcut
  • .nupkg.metadata is written last, which is how NuGet decides the install finished

A package already extracted by dnx or dotnet restore is reused. Packages ndnx writes are visible to dnx and restore.

Framework-dependent tools

Runner=executable (native / AOT tools) is unchanged.

Runner=dotnet is checked against the muxer (DOTNET_ROOT, then PATH), not ndnx's own compile-time TFM. If the tool needs .NET 10 and that dotnet only has 8.0.19, ndnx exits before launch:

This tool requires .NET 10.0. The 'dotnet.exe' at 'C:\Program Files\dotnet\dotnet.exe' has Microsoft.NETCore.App 8.0.19.

Packages with several tools/{tfm}/ groups pick the newest TFM that muxer can load.

Other

ndnx --version

prints the ndnx version and exits.

Assets 16
Loading