ACTool task fails build when xcrun actool cannot find tool

[AArnott]

Apple platform

iOS

Framework version

net8.0-, net9.0-

Affected platform version

.NET 9.0.100

Description

actool cannot be found, but only when in the context of dotnet build:

/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.1/18.1.9163/tools/msbuild/iOS/Xamarin.Shared.targets(907,3): /usr/bin/xcrun exited with code 72:
xcrun: error: sh -c '/Applications/Xcode_16.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode_16.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -find actool 2> /dev/null' failed with exit code 16384: (null) (errno=No such file or directory)
xcrun: error: unable to find utility "actool", not a developer tool or in PATH [/Volumes/Expansion/git/nerdbank.cryptocurrencies/src/Nerdbank.Zcash.App/Nerdbank.Zcash.App.iOS/Nerdbank.Zcash.App.iOS.csproj]

If I take exactly the command line from the error message and execute it directly, in the same terminal where I spawned dotnet build, it works:

sh -c '/Applications/Xcode_16.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode_16.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -find actool 2> /dev/null'

I get the path to the actool printed in stdout.

I suspect then that the problem is environment variables set by the ACTool msbuild task, but I can't tell because that information isn't captured by the binlog.

Steps to Reproduce

With the .NET 9.0.101 SDK installed on a mac:

dotnet new maui

Modify the csproj to target .NET 9. (why does the .NET 9 SDK create a .NET 6 targeted maui project anyway??)
Use xcode-select to verify that Xcode 16.1 is selected.

dotnet build -f net9.0-ios

Problem repros.

Did you find any workaround?

No.

Build logs

binlog: msbuild.zip

[AArnott]

This happens exactly when I switch to Xcode 16.1 (which .NET 9 targeting requires). If I switch back to Xcode 16.0, it works just fine.

[rolfbjarne]

This looks like a variation of #3931.

Can you try executing this script, to see if that shows the same error?

https://gist.github.com/rolfbjarne/0cfcd18e187102ad48402aefe2d0f2c4

why does the .NET 9 SDK create a .NET 6 targeted maui project anyway??

That sounds like a different bug (I don't see this behavior). I would suggest filing this in the MAUI repo.

[AArnott]

@rolfbjarne That script appears to have worked when targeting Xcode 16.1, both with and without the leading export statements.

[rolfbjarne]

@AArnott and building your project with dotnet build ... from the command line still fails?

[AArnott]

@rolfbjarne yes.

[rolfbjarne]

Can you add this to your csproj:

<Target Name="_PrintEnvironment" BeforeTargets="_CoreCompileImageAssets">
	<Exec Command="env -0 | sort -z | tr '\0' '\n' > /tmp/actoolenv.txt" />
</Target>

build your project (reproducing the error), and then attach the resulting /tmp/actoolenv.txt file here?

[AArnott]

Sure. Here you go, @rolfbjarne:
actoolenv.txt

[rolfbjarne]

XCODE_DEVELOPER_DIR_PATH=/Applications/Xcode_16.1.app/Contents/Developer

Something is configured to use /Applications/Xcode_16.1.app instead of /Applications/Xcode_16.app, and that confuses Xcode.

Do you have this file: ~/Library/Preferences/Xamarin/Settings.plist? If so, does deleting it fix the problem?

[AArnott]

Thanks, @rolfbjarne

Do you have this file: ~/Library/Preferences/Xamarin/Settings.plist? If so, does deleting it fix the problem?

That file does not exist.

Something is configured to use /Applications/Xcode_16.1.app instead of /Applications/Xcode_16.app, and that confuses Xcode.

Both of these are symbolic links. In the /Applications directory I have:

Xcode.app -> Xcode_16.app
Xcode_16.app -> Xcode_16.0.app
Xcode_16.0.app -> /Volumes/Expansion/Xcode_16.0.app/
Xcode_16.1.app -> /Volumes/Expansion/Xcode_16.1.app/

xcode-select -p emits:

/Applications/Xcode_16.1.app/Contents/Developer

It is important as part of the repro that we build with Xcode 16.1, so yes, we're using /Applications/Xcode_16.1.app instead of /Applications/Xcode_16.app, and that's by design.

[rolfbjarne]

Something is configured to use /Applications/Xcode_16.1.app instead of /Applications/Xcode_16.app, and that confuses Xcode.

Both of these are symbolic links. In the /Applications directory I have:

I've seen Xcode getting confused when dealing with symbolic links. Can you try using the real path instead as the Xcode path?

sudo xcode-select --switch /Volumes/Expansion/Xcode_16.1.app/

and see if that works?