Add warning MSB4280 when DOTNET_HOST_PATH is set to a directory

[Copilot]

Context

Roslyn build tasks and other SDK tools rely on DOTNET_HOST_PATH to locate the dotnet executable. When users set this variable to a directory path instead of a file path, builds fail with unhelpful error messages, making root cause difficult to identify.

Changes Made

• Added warning MSB4280 in BuildManager.BeginBuild that fires when DOTNET_HOST_PATH points to a directory
• Warning text includes the invalid path and guidance to fix
• Added exception handling using ExceptionHandling.IsIoRelatedException() pattern for graceful failure when checking the path
• Created EnvironmentVariableValidator.cs in src/Build/BackEnd/BuildManager/ to centralize environment variable validation logic:
  • Single public entry point ValidateEnvironmentVariables(ILoggingService) called from BuildManager
  • Private validation methods for each environment variable (currently ValidateDotnetHostPath)
  • Extensible design allowing future validations to be added without modifying BuildManager

Example output:

warning MSB4280: The environment variable DOTNET_HOST_PATH is set to a directory ("/tmp") instead of a path to the dotnet executable. This can lead to build errors in tasks that use this variable such as the Roslyn compiler. Either unset the variable or update it to point to the dotnet executable directly (e.g. "C:\Program Files\dotnet\dotnet.exe").

Testing

• DotnetHostPathDirectoryWarning: verifies warning when path is directory
• DotnetHostPathFileNoWarning: verifies no warning when path is file
• DotnetHostPathNotSetNoWarning: verifies no warning when unset

Tests use shared test infrastructure (_env, _buildManager, _parameters, _logger) for concise implementation.

Notes

Validation uses FileSystems.Default.DirectoryExists() to detect directories without introducing new filesystem abstractions. I/O exceptions are silently ignored since this validation is best-effort and should not cause build failures if the path cannot be checked.

The EnvironmentVariableValidator architecture is intentionally separate from the Traits class because:

• Traits is for feature flags (reading env vars to toggle behavior) and lives in Framework assembly without ILoggingService access
• EnvironmentVariableValidator is for value validation with logged warnings, requiring ILoggingService which is only available in the Build project
• These are fundamentally different patterns: feature flags vs. configuration validation

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Should MSBuild report a warning if DOTNET_HOST_PATH is set to a directory?</issue_title>
<issue_description>See https://developercommunity.visualstudio.com/t/VS-2026-fails-to-build-net-10-web-app/11011933 (https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2654293).

Roslyn build tasks use DOTNET_HOST_PATH variable set by MSBuild, I assume other tasks might do that too. If that variable is overwritten by the user from the outside to a directory path (instead of a file path), this leads to unhelpful errors, so it might be nice if MSBuild warned about that to help users determine the root cause.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Should MSBuild report a warning if DOTNET_HOST_PATH is set to a directory? #12911

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[dotnet-policy-service]

Hello @@copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.