[VanHerckArnaud]

Problem

On macOS (and Linux), the tool exits with:

Unable to find Microsoft.NETCore.App.Ref v10.0.x references. Searched in C:\Program Files\dotnet\packs\.

Two root causes, both in TypeContractor.Tool:

1. ReflectionContextHelper.GetNetCorePack joined paths with a literal backslash (@$"{packPath}\{packName}"). On Unix a backslash is a filename character, not a directory separator, so the lookup directory never exists.
2. The --packs-path option in Program.cs defaulted to the Windows-only path C:\Program Files\dotnet\packs\.

Fix

• ReflectionContextHelper.cs:47 — join with Path.Combine(packPath, packName), which uses the host separator and preserves Windows behavior.
• Added internal ReflectionContextHelper.GetDefaultPacksPath(), which derives <dotnet-root>/packs from RuntimeEnvironment.GetRuntimeDirectory() (up three levels from shared/Microsoft.NETCore.App/<version>/, then packs). This matches the standard layout on Windows, macOS, and Linux.
• Program.cs — --packs-path now falls back to GetDefaultPacksPath(). Explicit --packs-path and packs-path config-file values keep precedence as before.
• Test access only: InternalsVisibleTo("TypeContractor.Tests") on the tool project plus a project reference from the test project. No public API changes.

Tests

New TypeContractor.Tests/Tool/ReflectionContextHelperTests.cs:

• GetNetCorePack_Joins_Pack_Path_Without_Backslash — builds a fake Microsoft.NETCore.App.Ref/10.0.1/ref/net10.0 tree under a temp dir with Path.Combine and asserts the resolved path. Verified it fails against the old backslash implementation and passes with the fix.
• GetDefaultPacksPath_Exists_And_Contains_NetCore_Ref_Pack — asserts the auto-detected packs dir exists and contains Microsoft.NETCore.App.Ref against the real SDK layout.

Full suite green locally on macOS, Ubuntu CI expected to match since CI installs the SDKs before running tests.

Smoke test (macOS, no --packs-path)

Packed 0.22.2-local.1 locally (dotnet pack + dotnet tool install from a temp source), then ran it against a minimal net10.0 DTO controller assembly:

• Exit code 0, no Microsoft.NETCore.App.Ref / Microsoft.AspNetCore.App.Ref errors; debug log shows both resolved from the detected default (~/.dotnet/packs/...).
• Generated smoke/weather-dto.ts with the expected interface.
• Explicit --packs-path override re-run also exits 0.

[VanHerckArnaud]

Verified this against a real project as well, in addition to the smoke test above.

Setup

• macOS (Apple Silicon), .NET SDK 10.0.401 installed via Homebrew
  (/opt/homebrew/Cellar/dotnet/10.0.401/libexec, not ~/.dotnet)
• TypeContractor installed as a local tool via the repo's tool manifest
• Invoked from an MSBuild post-build step on a net10.0 ASP.NET Core project, without --packs-path

Result

• With 0.22.1: the build fails with the C:\Program Files\dotnet\packs\ error (MSB3073, exit code 1)
• With this branch (packed locally as 0.22.2-local.1): dotnet build succeeds and the TypeScript output is generated as expected

So the default packs-path detection also works with the Homebrew install layout, not just the standard ~/.dotnet one.