* Updated to use Xcode 16's new provisioning profiles directory
Starting with Xcode 16, the location of cached provisioning profiles
has moved from "~/Library/MobileDevice/Provisioning Profiles" to
"~/Library/Developer/Xcode/UserData/Provisioning Profiles"
Fixes https://github.com/xamarin/xamarin-macios/issues/20771
* Support loading profisioning profiles from both locations
* Fixed the unit tests
* Auto-format source code
---------
Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
We were accidentally getting the ProductBuildVersion value (which is used for
DTSDKBuild) from the system, not from the SDK used during the build.
This happened because we were trying to Path.Combine two rooted paths - in
which case Path.Combine returns the second path, without combining anything.
The fix is to compute the path of the plist where the ProductBuildVersion
value is located correctly.
Fixing the Path.Combine issue also revealed that the first path passed to
Path.Combine was wrong, so that got fixed too.
And finally make sure we don't Path.Combine two rooted paths anywhere else -
in all other cases we're supposed to just use the second path without
prepending the first, so just remove the Path.Combine call completely in those
cases.
Fixes https://github.com/xamarin/xamarin-macios/issues/19733.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
And make the MacOSXSdk and AppleSdk classes implement these new methods,
without changing any of the public API in these classes.
This makes it easier to share code between Xamarin.iOS and Xamarin.Mac, since
the IAppleSdk interface can be used in shared code, while the separate classes
can't.
Use what's returned by 'xcode-select -p' as the configured Xcode if none is
specified in Visual Studio's settings. It looks like this was the intention in
the code, but the code that calls 'xcode-select -p' would never execute,
because we'd only run into it if GetConfiguredSdkLocation returned null/empty,
which it never did because it returned the default location
'/Applications/Xcode.app' if nothing was configured in VSfM. With this change,
GetConfiguredSdkLocation will try to get the system's Xcode location
('xcode-select -p') before returning /Applications/Xcode.app.
Also remove /Developer as a default location, Xcode hasn't been there in many,
many years.
Now the order is:
1. Settings in Visual Studio's Preferences.
2. System's Xcode (xcode-select --print-path).
3. /Applications/Xcode.app
This avoids strange problems if the system's Xcode is not
/Applications/Xcode.app and there's no Xcode configured in Visual Studio's
settings.
Ref: https://github.com/xamarin/xamarin-macios/issues/10003
XSAccentColorAssets will be used as custom key for storing the path to the asset, and NSAccentColorName is the Apple key that contains the name of the asset that will be used as accent color by the OS
Jeffrey Stedfast
Emanuel Fernandez Dell'Oca
Rolf Bjarne Kvinge
Manuel de la Pena
Juan Diego Herrera
James Parsons
Kunyi Li
Stefani Moore
Stefani Moore
Juan Marcelo Tondato
Mauro Agnoletti
emaf
Joaquin Jares
Alex Soto
