Skip to content

Avoid xcodebuild probe error without Xcode during NativeAOT - #133105

Merged
akoeplinger merged 1 commit into
dotnet:mainfrom
akoeplinger:akoeplinger/fix-nativeaot-xcodebuild-stderr
Sep 3, 2026
Merged

Avoid xcodebuild probe error without Xcode during NativeAOT#133105
akoeplinger merged 1 commit into
dotnet:mainfrom
akoeplinger:akoeplinger/fix-nativeaot-xcodebuild-stderr

Conversation

@akoeplinger

@akoeplinger akoeplinger commented Sep 2, 2026

Copy link
Copy Markdown
Member

Description

On macOS machines with only the Command Line Tools installed, xcodebuild -version writes an xcode-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 IgnoreStandardErrorWarningFormat on the NativeAOT probe, matching the equivalent probes in crossgen-corelib.proj and Microsoft.NET.CrossGen.targets.

This is a regression from .NET 10, where this target checked clang --version instead of invoking xcodebuild.
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 clr on macOS with Command Line Tools installed but no Xcode

Note

This pull request description was generated with GitHub Copilot.

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

Copy link
Copy Markdown
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.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 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 -version probe to set IgnoreStandardErrorWarningFormat="true" so stderr diagnostics aren’t interpreted as MSBuild error/warning-formatted output.
  • Align NativeAOT’s probe behavior with existing xcodebuild probes 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

agocke commented Sep 2, 2026

Copy link
Copy Markdown
Member

Backport to 11?

@akoeplinger
akoeplinger merged commit a4ec83c into dotnet:main Sep 3, 2026
115 checks passed
@akoeplinger
akoeplinger deleted the akoeplinger/fix-nativeaot-xcodebuild-stderr branch September 3, 2026 08:20
@akoeplinger

Copy link
Copy Markdown
Member Author

/backport to release/11.0

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Started backporting to release/11.0 (link to workflow run)

@akoeplinger akoeplinger changed the title Avoid xcodebuild probe error without Xcode Avoid xcodebuild probe error without Xcode during NativeAOT Sep 3, 2026
@dotnet-milestone-bot dotnet-milestone-bot Bot added this to the 12.0-preview1 milestone Sep 4, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants