Microsoft.Dynamics.BusinessCentral.Development.Tools.Linux v17.x fails to install via dotnet tool install

[StefanMaron]

Describe the issue

All v17.x versions of the Microsoft.Dynamics.BusinessCentral.Development.Tools.Linux NuGet package fail to install as a .NET global tool on Linux. v16.x installs and works fine.

Since v17 is the latest stable version, running dotnet tool install -g Microsoft.Dynamics.BusinessCentral.Development.Tools.Linux without a version pin now fails by default.

Steps to reproduce

# Clean Ubuntu 24.04 with .NET 9 SDK
dotnet tool install -g Microsoft.Dynamics.BusinessCentral.Development.Tools.Linux

Actual result

.NET 9 SDK (9.0.313):

Unhandled exception: Could not find a part of the path
'/root/.dotnet/tools/.store/microsoft.dynamics.businesscentral.development.tools.linux/17.0.34.45391/microsoft.dynamics.businesscentral.development.tools.linux/17.0.34.45391/tools'.

.NET 10 SDK (10.0.104):

Package microsoft.dynamics.businesscentral.development.tools.linux is not a .NET tool.

Expected result

The tool installs successfully, as it does with --version '16.*'.

Versions tested

Package version	.NET 9	.NET 10
17.0.34.45391	Crash: missing path	"not a .NET tool"
17.0.33.55542	Crash: missing path	"not a .NET tool"
16.2.28.57946	Works	Works

Environment

• OS: Ubuntu 24.04 (amd64)
• Also reproduced in mcr.microsoft.com/devcontainers/base:ubuntu-24.04 Docker container

[StefanMaron]

Additional findings: regression bisected

Tested all available v17 and v18 prerelease versions. The regression was introduced in 17.0.29:

Version	Result
17.0.27.27275-beta	✅ Works
17.0.28.6483-beta	✅ Works
17.0.29.41701-beta	❌ Broken (first failure)
17.0.29.44223-beta	❌ Broken
17.0.29.57863-beta	❌ Broken
17.0.30.30339-beta	❌ Broken
17.0.30.49729-beta	❌ Broken
17.0.32.53955-beta	❌ Broken
17.0.33.55542	❌ Broken
17.0.34.45391	❌ Broken
18.0.33.30146-beta	❌ Broken
18.0.33.65164-beta	❌ Broken
18.0.35.14686-beta	❌ Broken

All versions from 17.0.29 onward (including all v18 betas) fail with the same Could not find a part of the path '.../tools' error. Something changed in the package structure between 17.0.28 and 17.0.29.

[StefanMaron]

We ran into this as well in BusinessCentral.AL.Runner. The v17.0.34.45391 package changed its internal layout from tools/net8.0/any/ to lib/net8.0/, which explains both the dotnet tool install failure and why direct NuGet extraction breaks for consumers expecting the old path.

Our workaround: we download the .nupkg directly and extract DLLs from both tools/net8.0/any/ (v16) and lib/net8.0/ (v17) paths, bypassing dotnet tool install entirely (PR #1320).

The regression appears to be in the NuGet package metadata — moving from tools/ to lib/ means the package no longer qualifies as a .NET tool, which is why dotnet tool install rejects it.