Acuminator CLI 4.0.1 build host fails with `XMakeElements` initialization error when a newer Visual Studio installation is present

[EvanTrow]

Description

Acuminator CLI 4.0.1 stops during build-host initialization before analyzing a valid .NET Framework customization project. The failure occurs on a Windows workstation where Visual Studio 2026 Enterprise Insiders 18.9 and Visual Studio 2026 Community 18.8 are installed alongside older build tools.

Passing the compatible MSBuild directory through --msBuild-path does not appear to keep the build host from discovering or loading components from the newer Visual Studio installation.

The same project can be analyzed successfully with Acuminator CLI 4.0.0 when it is launched with an isolated MSBuild 17.14.28 and Roslyn 5.0 environment.

Steps to Reproduce

1. On Windows, install Visual Studio 2026 18.x alongside an MSBuild 17 installation. In the affected environment, the newest discovered instance is Visual Studio 2026 Enterprise Insiders 18.9.12023.133 with MSBuild 18.9.1.

2. Use a .NET Framework 4.8.1 project configured for C# 9.0.

3. Run Acuminator CLI 4.0.1 and explicitly provide the MSBuild 17 binary directory:

   Acuminator.Runner.NetFramework.exe `
       "C:\Repos\SampleCustomization\SampleCustomization.csproj" `
       --msBuild-path "C:\BuildTools\MSBuild\Current\Bin" `
       --format json `
       --file "C:\Temp\acuminator-results.json" `
       --output-absolute-paths-for-errors `
       --verbosity Information

4. Observe that the runner stops before project analysis begins.

Expected Behavior

The runner should use the MSBuild installation supplied through --msBuild-path, load the project, and return Acuminator diagnostics.

If the supplied MSBuild installation is incompatible, the runner should report which MSBuild instance and assemblies it attempted to load.

Actual Behavior

The build host terminates with a TypeInitializationException involving:

Microsoft.Build.Shared.XMakeElements

No Acuminator diagnostics are produced because the failure occurs before analysis.

The behavior suggests that the out-of-process build host may be selecting the newest discovered Visual Studio/MSBuild installation independently of the --msBuild-path value supplied to the runner.

Environment

Operating System and Runtime

Component	Local version
Windows	Windows 10 IoT Enterprise LTSC 2024, version 24H2, build 26100.8655
.NET Framework 4.x	4.8.1 (4.8.09032, release key 533320)
PowerShell used to launch the runner	7.6.3
Project target framework	.NET Framework 4.8.1
Project language version	C# 9.0
ERP application version referenced by the project	25.201.0213

Acuminator Versions

Package	Result
Acuminator CLI 4.0.1	Fails during build-host initialization before analysis
Acuminator CLI 4.0.0	Completes successfully with the isolated toolchain below

Installed Visual Studio and Build Tools

Installation	Installation version	MSBuild file version	Roslyn compiler version	Role in reproduction
Visual Studio Enterprise 2026 Insiders	18.9.12023.133	18.9.1.35102	5.9.0-1.26357.3	Newest discovered instance; present when 4.0.1 fails
Visual Studio Community 2026	18.8.12021.73	18.8.2.30814	5.8.0-1.26319.2	Stable Visual Studio 2026 instance also installed
Visual Studio Build Tools 2019	16.11.35931.194	16.11.2.50704	3.11.0-4.22108.8	Older local toolchain; not used by the successful run

Successful Isolated Toolchain

Component	Version
MSBuild package	17.14.28
Roslyn compiler toolset package	5.0.0
Acuminator CLI	4.0.0

The MSBuild 17.14.28 and Roslyn 5.0.0 values above are package versions from the isolated toolchain. They are intentionally distinguished from the file versions of the products installed on the workstation.

Workaround

The analysis completes successfully with Acuminator CLI 4.0.0 when all of the following are done:

1. Launch Acuminator CLI 4.0.0 with the isolated MSBuild 17.14.28 package and Roslyn compiler toolset 5.0.0.
2. Configure the Visual Studio environment variables so the build host resolves the same MSBuild 17 toolchain.
3. Normalize the child-process environment so only one case-insensitive Path variable is present.
4. Run the CLI with a valid console handle.

With that configuration, the project is loaded successfully and the runner exits with code 0 after analysis.

Additional Observations

• The project builds successfully outside Acuminator with the compatible MSBuild toolchain.
• Acuminator CLI 4.0.0 can fully analyze the project in the isolated environment, which indicates the project itself is loadable.
• A Visual Studio 2019 compiler is not sufficient for this reproduction because the project uses C# 9.0.
• The duplicate Path/PATH environment issue and missing-console issue were handled before comparing versions. The 4.0.1 build-host failure remained afterward.

Requested Guidance

Could the build host honor the --msBuild-path selection passed to the runner, or provide a supported option to force the MSBuild instance used by both the runner and its build-host process?

It would also help if verbose output identified the resolved Visual Studio instance, MSBuild executable directory, compiler directory, and loaded Microsoft.Build assembly versions before project evaluation.

[SENya1990]

@EvanTrow thank you for a detailed report.
I have created a Jira ticket internally for this issue.

[SENya1990]

@EvanTrow could you please check that the bug reproduces on the latest feature build of Acuminator Console Runner?
I have built it and attached an archive with it to this comment
AcuminatorCLI.zip