This is an improvement on how we detect if the file that is going to be copied to the Mac is coming from the output path or not. Copying files from the Windows output dir to the Mac will make the build fail.
There were two problems:
- The paths we were comparing could contain different path separators.
- The item we are trying to copy may be in a folder that is inside the output dir.
For example:
- OutputFile = `obj\Debug\net6.0-ios\iossimulator-x64\nativelibraries/Foo`
- Item to copy: `obj/Debug/net6.0-ios/iossimulator-x64/nativelibraries/aot-output/x86_64/System.Private.CoreLib.dll.o`
The `_AdditionalTaskAssembly` prop was already fixed by 7c66aa3829, so we don't need to do this anymore. This breaks building from Windows because we're missing custom steps.
I missed adding this file to that commit.
On CI we'll collect all the binlogs in the repository and make them available
for post-build analysis if need be, so this will make it easier to diagnose
build problems.
* Rearrange some MSBuild logic so that the packaging/archiving code for macOS
can also be used for Mac Catalyst.
* Make the .NET build logic package/archive when requested to do so.
* Add tests.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/10413.
* [net6] Adds missing custom linker steps when building from Windows
To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`.
When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS.
* [net6] Updates .NET SDK path for remote tasks execution
This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist.
* Adds missing spaces to TaskRunner.cs
There was a main version of this target for Xamarin.iOS, and then numerous dummy targets for two scenarios:
* Building app extensions.
* Building macOS apps.
The first one is handled by the '_CanArchive' property (will be false when
building app extensions), and for the second case I've added it to the
condition on the CreateIpa target.
This way we don't have to have logic elsewhere about when it's valid to call
CreateIpa.
We fail later with an uninformative error ('The "Archive" task was not given a
value for the required parameter "SigningKey"') otherwise, and this way the
user doesn't have to manually enable signing to avoid the this error.
We use two different properties for the same thing: MtouchEnableSGenConc and
EnableSGenConc. Going forward, we're sticking with just EnableSGenConc, but
we'll keep accepting MtouchEnableSGenConc if it's set.
* Add support for the interpreter everywhere.
* Add support for the AOT compiler everywhere we didn't support it before,
because the interpreter needs it (at least System.Private.CoreLib.dll must
be AOT-compiled when using the interpreter).
* Do FullAOT compilation on Mac Catalyst/ARM64 if we're not using the
interpreter, since we can't use the JIT.
* Fix monotouch-test to be green on Mac Catalyst/ARM64.
Fixes https://github.com/xamarin/xamarin-macios/issues/11724.
Fixes https://github.com/xamarin/xamarin-macios/issues/11421.
The iOS version and the Mac version were slightly different in that they were
adding different things to the archive, but both seemed to be resilient to
those files not existing, so I just merged both implementations to try to add
everything to the archive.
Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the
TargetArchitectures property from either the RuntimeIdentifier or
the RuntimeIdentifiers properties.
Also make sure this target is executed before _ComputeTargetArchitectures.
This is required so that we have a correct TargetArchitectures value for
multi-rid builds when compiling the app manifest (Info.plist).
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
The iOS version of the cleaning tasks were much more comprehensive, so those
won out when there were any differences.
This also required moving the GetDirectoriesTask to shared code.
The native 'stat' function is not identical between x64 and arm64:
* The x64 version is the 32-bit version of the function, and takes a 32-bit
version of the stat structure.
* The arm64 version is the 64-bit version of the function, and takes a 64-bit
version of the stat structure.
We used the 32-bit version of the stat structure everywhere, which went
horribly wrong on arm64, because the layout and size of the struct is quite
different (120 bytes vs 144 bytes). The actual result on arm64 was that the
call to stat would null out one of the parameters to the calling function, and
the C# code would throw an ArgumentNullException when the code tried to use
that argument, and you'd end up with this exception which didn't make any
sense at all when looking at the code:
error : System.ArgumentNullException: Parameter "itemSpec" cannot be null. [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName, String resourceName) in Microsoft.Build.Utilities.Core.dll:token 0x6000121+0x20 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName) in Microsoft.Build.Utilities.Core.dll:token 0x6000120+0x0 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Utilities.TaskItem..ctor(String itemSpec) in Microsoft.Build.Utilities.Core.dll:token 0x60003ba+0x6 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.CopyFile(String source, String target, String targetItemSpec) in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 74 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 99 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
So fix the P/Invoke to stat:
* Use the 64-bit version of the stat struct.
* For x64, call the 64-bit version of stat (stat$INODE64), since we're now
using the 64-bit version of the stat struct.
* For arm64, call the standard version of stat (which is the 64-bit version).
And this means that we can now use the ARM64 version of .NET to build .NET
apps.
The entire `.framework` directory needs to be copied back to Windows
when a native reference is a [xc]framework. Otherwise important files
will be missing and the app bundle will be unusable.
Fix https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1339824
Emanuel Fernandez Dell'Oca
Mauro Agnoletti
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
Sebastien Pouliot