Avoid xcodebuild probe error without Xcode during NativeAOT - #133105
Merged
akoeplinger merged 1 commit intoSep 3, 2026
Merged
Conversation
The Xcode version probe is allowed to fail, but MSBuild recognizes the xcode-select stderr output as an error when only the Command Line Tools are installed. Ignore the standard error warning format, matching the other xcodebuild probes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9803f1dc-6ff0-43e2-9aff-e10f1c0b3fb2
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The change is a minimal, low-risk alignment with existing repo patterns for xcodebuild probing and should prevent erroneous MSBuild failures without altering functional build behavior.
Pull request overview
This PR adjusts the NativeAOT macOS toolchain probing in Microsoft.NETCore.Native.Unix.targets to avoid MSBuild failures caused by xcodebuild -version emitting xcode-select : error : ... on stderr when only Command Line Tools are installed (no full Xcode).
Changes:
- Update the
xcodebuild -versionprobe to setIgnoreStandardErrorWarningFormat="true"so stderr diagnostics aren’t interpreted as MSBuild error/warning-formatted output. - Align NativeAOT’s probe behavior with existing
xcodebuildprobes already using the same setting elsewhere in the repo.
File summaries
| File | Description |
|---|---|
| src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets | Adds IgnoreStandardErrorWarningFormat to the xcodebuild -version probe to prevent stderr formatting from failing NativeAOT publishing on macOS without Xcode. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
agocke
approved these changes
Sep 2, 2026
Member
|
Backport to 11? |
lewing
approved these changes
Sep 2, 2026
Member
Author
|
/backport to release/11.0 |
Contributor
|
Started backporting to |
4 tasks
artl93
pushed a commit
that referenced
this pull request
Sep 5, 2026
Backport of #133105 to release/11.0 /cc @akoeplinger ## Customer Impact - [X] Customer reported - [X] Found internally On a macOS machine without Xcode installed (using just Command Line Tools) publishing a NativeAOT app fails with an error: > xcode-select : error : tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance This is basically the same as this report from 9.0 timeframe in #100189 that we fixed back then and now regressed. ## Regression - [X] Yes - [ ] No Regression was introduced in [`25f2dcb` (#123386)](25f2dcb) when we switched checking the output of `clang --version` to `xcodebuild --version`. The previous behavior worked in the past when the clang version was aligned to the Xcode version (specifically for 15 and 16 which we're using to decide whether to use classic ld) but nowadays it's not aligned anymore so switching to checking the xcodebuild version is the correct fix. The issue is that although the check already ignored the exit code, MSBuild recognizes the stderr line as a standard error and fails the build. The fix is to set `IgnoreStandardErrorWarningFormat` on the check, matching the equivalent probes in `crossgen-corelib.proj` and `Microsoft.NET.CrossGen.targets`. ## Testing Tested manually on a machine without Xcode. It was missed because most users use Xcode but there are some that don't as we got reports about a similar issue before. ## Risk Low. We just make sure to ignore the error output like we do in other places. **IMPORTANT**: If this backport is for a servicing release, please verify that: - For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`, not `release/X.0`. - For .NET 10+: The PR target branch is `release/X.0` (no `-staging` suffix). ## Package authoring no longer needed in .NET 9 **IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions. Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com> Copilot-Session: 9803f1dc-6ff0-43e2-9aff-e10f1c0b3fb2
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
On macOS machines with only the Command Line Tools installed,
xcodebuild -versionwrites anxcode-select : error :diagnostic to stderr. Although this probe already ignores its exit code, MSBuild recognizes that stderr line as a standard error and fails the NativeAOT publishing projects.Set
IgnoreStandardErrorWarningFormaton the NativeAOT probe, matching the equivalent probes incrossgen-corelib.projandMicrosoft.NET.CrossGen.targets.This is a regression from .NET 10, where this target checked
clang --versioninstead of invokingxcodebuild.This worked in the past when the clang version was aligned to the Xcode version (specifically for 15 and 16 which we're using to decide whether to use classic ld) but nowadays it's not aligned anymore and will fail the build if Xcode isn't installed.
It changed in
25f2dcb(#123386).Testing
./build.sh clron macOS with Command Line Tools installed but no XcodeNote
This pull request description was generated with GitHub Copilot.