Fix AL tool compatibility across BC versions

[Sun Haoran (haoranpb)]

Summary

• select the AL development tools .NET version from each entry's BC platform version
• use .NET 8 for BC 24-28 and .NET 10 for BC 29+ in both Claude Code and Copilot workflows
• remove historical Scope = OnPrem table declarations during setup_repo_prebuild and commit that common baseline
• bump BC-Bench to 0.10.1

Why

Microsoft.Dynamics.BusinessCentral.Development.Tools ships net8.0 and net10.0 payloads. On Windows 2025 runners, an unqualified install selected net10.0 for BC 24 and BC 27 entries even though those platforms require .NET 8. This caused false TimeSpan.FromSeconds overload errors.

After fixing that mismatch, the full run exposed a second, older incompatibility: public AL MCP compilers reject historical Microsoft BaseApp tables containing Scope = OnPrem with AL0850.

setup_repo_prebuild now removes those declarations and commits the result as the baseline. Every agent and evaluator therefore sees the same adjusted source whether AL MCP/LSP is enabled or not, keeping experiments comparable and matching the previously proven approach. The rewrite is limited to table files under each entry's project paths. Current dataset patches neither contain the removed line nor target the rewritten tables, and a test guards that invariant.

Previous attempts and history

• Refactor AL MCP server setup after latest update #583 introduced the original Scope = OnPrem source rewrite while moving AL MCP to its stdio integration.
• Fix/remove scope onprem changes is pickedup as output #589 committed the rewritten source as a baseline so compatibility edits would not appear in generated agent patches.
• fix al mcp compile in BC-Bench #592 fixed assembly probing and conflicting symbols, but removed the scope rewrite during that refactor even though the public compiler restriction remained. This is when the AL0850 blocker was reintroduced.
• Pinning BcContainerHelp and uv versions & switch to process isolation #624 temporarily pinned BcContainerHelper 6.1.12 and switched container isolation while investigating related runtime failures.
• Revert back to latest BCCH #631 returned BC-Bench to the latest BcContainerHelper after the upstream/runtime path improved.
• Remove .NET 10 assemblies from container to fix v24 BC compilation #634 attempted to remove .NET 10 assemblies from older containers; it was closed in favor of the narrower approach in Fix v24 tasks build failed due to .NET 10 #636.
• Fix v24 tasks build failed due to .NET 10 #636 injected a .NET 8 manifest for BC 24 so BcContainerHelper's in-container compiler would not probe .NET 10. It did not cover the separate host-side AL MCP process addressed here.
• Use manifest.json dotNetVersion for .NET assembly probing paths navcontainerhelper#4130 added manifest-based .NET probing support. [Draft] Add Get-DotNetMajorVersionForPlatform helper for .NET version fallback navcontainerhelper#4136 proposed a BC-version fallback for missing manifests but closed without merge.

Validation

• uv run pytest tests\test_setup_operations.py tests\test_review_workflows.py tests\test_git_operations.py tests\test_claude_code_agent.py tests\test_copilot_agent.py tests\test_type_exhaustiveness.py -q (55 passed)
• uv run pre-commit run --all-files
• verified BC 24/27 select .NET 8 and BC 29 selects .NET 10
• verified current dataset patches do not depend on the removed scope declarations
• Simplified prebuild smoke run 33879644151 passed all jobs; BC 24 and BC 27 baselines removed and committed the expected declarations, built/published successfully before and after agent execution, and emitted no AL0850 or AL0196

[Sun Haoran (haoranpb)]

Follow-up from evaluation run 33856550710: the framework fix is working. BC 27 jobs install the AL tool with --framework net8.0, and the previous \AL0196\ / \TimeSpan.FromSeconds\ ambiguity is gone. The linked job completed successfully; its evaluator build, publish, and regression test all passed.

One separate agent-side diagnostic remains: \AL0850\ on the historical \TableRelationsBuffer.Table.al\ object's \Scope = OnPrem. This is an explicit restriction in the public AL compiler, reproduces in both AL tool v17 and v18, and cannot be suppressed by a ruleset. It is not a .NET runtime problem. The authoritative BcContainerHelper build accepts that historical Microsoft source and succeeds.

The run's current actual failed matrix job is \microsoftInternal__NAV-227219: Docker failed during container startup with \hcs::System::Start: context deadline exceeded, then could not detach the VHD. That is a separate transient runner/container failure.

[Sun Haoran (haoranpb)]

Fresh validation on commit \

[Sun Haoran (haoranpb)]

Comparability follow-up in \8cfbb9e: the source compatibility layer is now enabled for every bug-fix/test-generation Claude and Copilot run, not only AL MCP/LSP experiments. The category registry owns the decision, so tool-enabled and tool-disabled runs see the same agent source; restoration before patch extraction/grading remains unchanged.

[Sun Haoran (haoranpb)]

Simplified baseline validation passed: run 33879644151 completed successfully on \4f5ae16. BC 24 removed/committed 2 restricted declarations; BC 27 removed/committed 1. Initial and post-agent BcContainerHelper builds published successfully, with no \AL0850\ or \AL0196. Expected benchmark test failures remain result-level outcomes, not infrastructure failures.